> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/ko/guardian/get-started/security-best-practices.md).

# 보안 모범 사례

## **개요**

Guardian을 의료기기에 통합할 때는 보안을 적절히 구현하는 것이 중요합니다. Guardian 파일 자산을 적절히 보호하고 기기의 전체 수명 주기 동안 보안을 유지하려면 다음 모범 사례를 따르세요.

## **Guardian 파일 자산 보안**

Guardian은 서로 다른 보안 요구 사항이 적용되는 세 가지 파일 자산 그룹을 사용합니다.

* **시스템 파일** (이전 명칭: **사전 로드 파일(PLF):** 시스템의 기반이 되는 파일입니다. 제조 과정에서 로드하거나 서명된 소프트웨어 업데이트를 통해 로드해야 합니다. 항상 쓰기 방지 상태로 유지해야 하며 직접 업데이트해서는 안 됩니다.
* **프로비저닝 패키지** (이전 명칭: **초기 프로비저닝 파일(IPF):** 여기에는 장치 초기 설정을 위한 부트스트랩 파일이 포함되어 있으며, 장치를 처음 프로비저닝할 때 사용됩니다. 이러한 파일은 "부분적으로 신뢰할 수 있는" 파일 패키지이므로 통제된 환경에서만 배포해야 합니다. 가능하면 제조 과정에서 로드하고 프로비저닝 직후 제거해야 합니다.
* **장치 파일** (이전에는 **프로비저닝된 파일(PF):** 여기에는 각 장치의 고유한 ID와 자격 증명이 포함되며, 프로비저닝 과정에서 생성되거나 가져옵니다.

## TPM 요구 사항

Guardian에는 Trusted Platform Module(TPM)이 필요하지 않지만, TPM을 사용할 수 있는 경우 추가 보안을 위해 활용할 수 있습니다.

## 인증서 형식

Guardian은 표준 X.509 인증서와 메모리 제약이 있는 장치에 최적화된 Medcrypt 독점 인증서를 모두 지원합니다. 추출하는 인증서는 표준 만료일이 있는 일반 X.509 인증서이므로 일반적인 방식으로 검사할 수 있습니다.

## 파일 복구 시나리오

Guardian 파일 손실의 영향은 어떤 파일이 언제 손실되었는지에 따라 달라집니다:

* **개발 중:** 인프라가 관여하기 전에는 언제든지 키를 다시 생성하고 처음부터 시작할 수 있습니다.
* **최초 업로드 후:** 다음 파일인 `.mcpi` 및 `.mcpr` 은(는) 온전하게 보존해야 합니다. 프로비저닝이 완료되기 전에 `.mcpr` 파일이 손실되면 프로세스를 다시 시작해야 합니다.
* **프로비저닝에 성공한 후:** 사용자의 `.mcpi`  파일은 손상되지 않은 상태로 유지해야 합니다.  `.mcp`  파일은 동일한  `.mcpr`  파일을 다시 제출하면 가져올 수 있습니다.

**중요:** .mcpi 파일이 언제든 손실되면 키와 프로비저닝된 구성 요소를 사용할 수 없게 됩니다.

## **디스크 암호화**

디스크 암호화의 목적은 저장된 파일 자산을 보호하는 것입니다. 디스크 암호화에 적합한 방법은 저장 시 별도로 보호되는 암호화 키(예: TPM 사용)를 활용해야 합니다.

## **쓰기 보호**

#### **root 권한으로 실행되는 경우**

Guardian 파일 자산에 액세스하는 프로세스가 root 권한으로 실행되는 장치에서는 파일 속성(호환되는 파일 시스템/OS를 사용하는 경우)을 설정하거나 디스크를 읽기 전용으로 마운트하여 쓰기를 보호할 수 있습니다. 두 방법 모두 파일 자산의 소유자는 root여야 하며 권한은 u-w,g-w,o-w로 설정해야 합니다.

#### **root 권한 없이 실행되는 경우**

Guardian 파일 자산에 액세스하는 프로세스가 root 권한 없이 실행되는 장치에서는 시스템 파일의 소유자를 root로 설정하고 파일 권한을 u-w,g-w,o-w로 설정하여 쓰기를 보호할 수 있습니다(필요에 따라 파일 속성을 설정하거나 읽기 전용으로 마운트할 수도 있습니다). 일부 시나리오에서는 프로비저닝 패키지 및 장치 파일에 쓰기 권한이 필요하므로, 해당 파일은 특수한 "provisioning user"가 소유하고 기록하도록 해야 합니다(권한은 u+w,g-w,o-w로 설정).

## **읽기 보호**

#### **root 권한으로 실행되는 경우**

Guardian 파일 자산에 액세스하는 프로세스가 root 권한으로 실행되는 장치에서는 파일 자산의 파일 권한을 u-r,g-r,o-r로 설정하여 읽기를 보호할 수 있습니다.

#### **root 권한 없이 실행되는 경우**

Guardian 파일 자산에 액세스하는 프로세스가 root 권한 없이 실행되는 장치에서는 파일 자산이 위치할 특수한 "guardian-asset" 그룹을 만들고 파일 자산의 파일 권한을 u+r,g+r,o-r로 설정하여 읽기를 보호할 수 있습니다. 이러한 파일 자산에 액세스해야 하는 프로세스는 이 그룹에 속한 사용자가 실행해야 합니다.

#### **파일 기록(프로비저닝)**

적절한 경로에 디바이스 파일을 기록하면 디바이스 초기 프로비저닝은 간단합니다. 가능하면 프로비저닝 패키지도 삭제해야 합니다.

그러나 프로비저닝을 다시 수행할 때는 활성 디바이스 파일 세트와 새로 생성 중인 세트, 두 가지가 존재합니다. 프로비저닝 과정에서 활성 세트를 덮어쓰지 않도록 각별히 주의해야 하며, 일반적으로 심볼릭 링크, 환경 변수 또는 디스크 재마운트와 같은 전환 전략을 사용해야 합니다.

#### **디바이스 보안을 위한 추가 모범 사례**

키의 보안을 확보하는 것이 무엇보다 중요합니다. 키는 JTAG 또는 유사한 기법을 이용한 데이터 유출이 불가능한 메모리 영역에 저장해야 합니다. 수명 주기의 어느 단계에서도 개인 키가 디바이스 외부로 전송되지 않고 디바이스 내부에 유지되도록 해야 합니다.

## **프로비저닝 보안 고려 사항**

초기 프로비저닝 중에는 **디바이스 파일** 을 적절한 경로에 기록하고 **프로비저닝 패키지** **파일을** 즉시 삭제합니다. 다시 프로비저닝할 때는 새 파일 세트를 생성하는 동안 활성 파일을 덮어쓰지 않도록 전환 전략(심볼릭 링크, 환경 변수 또는 디스크 재마운트)을 사용합니다.

## **디바이스 보안 기본 원칙**

JTAG 또는 유사한 방법을 이용한 데이터 유출이 불가능한 메모리 영역에 키를 저장합니다. 수명 주기의 어느 단계에서도 개인 키가 디바이스 외부로 나가서는 안 됩니다. 적절한 접근 제어와 모니터링을 구현하여 무단 접근 시도를 탐지합니다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.medcrypt.com/ko/guardian/get-started/security-best-practices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.