hardenconfig.py·hardened.csv다. 아래 도식은 개발자가 수행할 검토 흐름을 새로 그린 것이다. 특정 보드의 보호 기능이 동작한다거나 이 글의 설정만으로 제품이 안전·인증되었다는 주장은 아니다.1. 위협, 설정, 실행, 판정은 서로 다른 근거다
예를 들어 현장 장치의 디버그 인터페이스가 공격 표면이라면, 먼저 누가 어떤 접근으로 무엇을 얻을 수 있는지 정의한다. 그다음 필요 없는 서비스를 빌드에서 빼거나 접근 조건을 정한다. 그 결과가 .config에 반영됐는지, 이미지와 장치에서도 기대한 경계가 유지되는지 확인한다. 설정표에서 FAIL이 사라지는 것은 이 사슬의 한 단계일 뿐이다.
↔ 왼쪽에서 오른쪽으로 읽으며 각 단계의 질문을 구분하세요.
.config와 산출물이 설계를 반영하는가?hardenconfig는 구성 비교의 한 도구| 근거 | 확인할 질문 | 그 자체로 입증하지 못하는 것 |
|---|---|---|
| 위협 모델·보안 설계 | 어떤 자산과 공격 경계를 보호하려는가? | 구현과 실기 동작의 정확성 |
| 리뷰·결함 관리 | 변경의 보안 영향을 검토하고 추적했는가? | 모든 취약점의 부재 |
.config·hardenconfig | 빌드가 선택한 Kconfig 값은 무엇이며 권장값과 어떻게 다른가? | 보드별 하드웨어 보호의 실제 효력 |
| 이미지·장치 시험 | 정해진 위협 시나리오에서 어떤 동작이 관측되는가? | 시험하지 않은 모든 환경의 안전성 |
근거: 3.7.0 Security Overview의 개발·설계·인증 근거 구분과 Hardening Tool의 구성 비교 범위.
2. 보안 프로세스 문서는 구현 약속과 동일하지 않다
3.7.0 Security Overview는 Secure Development, Secure Design, Security Certification을 보안 프로세스의 단계로 나눈다. 마지막 단계의 평가 대상·자산·보호 근거는 정의하고 뒷받침해야 할 과제로 설명된다. 따라서 문서에 ‘shall’이 쓰였다고 특정 제품의 인증이 끝났다고 읽으면 안 된다. Secure Coding도 Zephyr 프로젝트에 기여되는 코드가 따를 설계·리뷰·이슈 관리 원칙을 기술한다. 제품 팀에는 이를 자기 자산·보드·업데이트 경로로 옮기는 작업이 남는다.
| 문서의 축 | 3.7.0 문서가 강조하는 일 | 제품 팀의 별도 산출물 예시 |
|---|---|---|
| Secure Development | 아키텍처·코딩 원칙·품질 절차 | 변경 리뷰, 정적 분석 결과, 재현 가능한 빌드 기록 |
| Secure Design | 자산·위협·대응책, 코드 검토와 문제 보고 | 장치별 위협 모델, 경계·입력·복구 설계 |
| Security Certification | 평가 대상과 보호 주장에 맞는 증거 정의 | 적용 표준·평가 범위에 맞춘 별도 평가 자료 |
Secure Coding의 최소 권한, 안전한 기본값, 완전한 매개, 공격 표면 축소는 설정 하나에 대응하는 체크박스가 아니라 설계 질문이다. 예컨대 사용하지 않는 관리 인터페이스를 끄는 것은 공격 표면 축소지만, 필요한 인터페이스를 남긴다면 호출 권한과 입력 검증도 다시 봐야 한다. 코드 리뷰와 이슈 추적은 이런 결정을 변경 이력에 묶는다.
| 원칙 | 장치 설계 질문 | 남길 근거 |
|---|---|---|
| 최소 권한 | 이 스레드·서비스가 모든 객체·명령에 접근해야 하나? | 호출 경계와 권한 검토 |
| 안전한 기본값 | 명시적 허가가 없을 때 접근을 거부하는가? | 기본 구성과 거부 시험 |
| 공격 표면 축소 | 현재 제품에 필요 없는 프로토콜·디버그 기능은 무엇인가? | 최종 빌드의 활성 기능 목록 |
| 방어 심층화 | 한 계층이 실패해도 다른 제한이 남는가? | 경계별 실패 시험과 위협 모델 |
3. 3.7.0 hardenconfig는 보이는 불일치 목록을 출력한다
공식 3.7.0 문서의 사용 순서는 애플리케이션을 빌드한 뒤 west build -t hardenconfig를 실행하는 것이다. 같은 태그의 hardenconfig.py는 현재 Kconfig를 불러오고 scripts/kconfig/hardened.csv의 권장값과 비교한다. 소스의 출력 루프는 FAIL이면서 그 심볼의 visibility가 0이 아닌 행만 출력한다. PASS, 존재하지 않는 심볼의 NA, 현재 선택할 수 없는 심볼은 표에 나타나지 않는다. 이 도구는 설정 파일을 고치거나 실행 경로를 시험하지 않는다.
↔ 두 입력이 비교 결과로 모이고, 출력 조건에서 다시 좁혀집니다.
kconf.load_config()대상 빌드가 계산한 심볼의 현재 문자열 값과 visibility를 읽는다.scripts/kconfig/hardened.csv심볼 이름과 Security Working Group 권장값을 순서대로 읽는다.FAIL && visibility != 0값이 다르고 현재 보이는 심볼만 현재값·권장값과 함께 출력한다.# 3.7.0 공식 문서의 예시 빌드 뒤에 실행
west build -b reel_board samples/hello_world
west build -t hardenconfig.config를 고정하고 같은 타깃을 실행해야 한다.| 내부 결과·조건 | 3.7.0 출력 | 읽는 법 |
|---|---|---|
| 현재값 ≠ 권장값, visibility ≠ 0 | FAIL 행 출력 | 해당 보드에서 변경 가능성과 영향 검토 |
| 현재값 = 권장값 | 출력 안 함 | CSV 항목의 값이 같다는 뜻에 한정 |
| 심볼 부재 또는 visibility = 0 | 출력 안 함 | 미지원·의존 조건 등 맥락을 별도 확인 |
근거: 공식 사용법, 태그된 도구 구현, 태그된 권장값 CSV.
4. CSV의 권장값은 위협과 사용 목적에 맞춰 결정한다
3.7.0 CSV에는 노출 축소와 실행 보호에 관한 항목이 함께 있다. 다음 표는 그중 실제 파일에 있는 값을 골라 검토 질문으로 옮긴 것이다. 단순히 모든 권장값을 복사하면 제품의 진단·복구 기능이나 보드 지원 조건을 놓칠 수 있다. 필요 기능을 유지해야 한다면 잔여 위험과 보완책을 기록한다.
| CSV의 항목·값 | 검토할 위험 | 현장에서 확인할 조건 |
|---|---|---|
CONFIG_SHELL=n | 대화형 명령 표면 | 생산 이미지에 Shell이 필요한가? 남긴다면 접근 경로·명령 권한은? |
CONFIG_PRINTK=n | 불필요한 진단 출력 | 오류 복구와 민감 정보 노출 사이의 제품 정책은? |
CONFIG_BOOT_BANNER=n | 부팅할 때 구현 정보 노출 | 진단에 필요한 식별 정보는 다른 안전한 경로로 얻는가? |
CONFIG_HW_STACK_PROTECTION=y | 스택 오버런 대응 | 이 보드·아키텍처에서 선택 가능하고 실제 보호가 작동하는가? |
CONFIG_STACK_SENTINEL=y | 스택 손상 감지 | 감지 지점·예외 처리·타이밍을 실기에서 확인했는가? |
CONFIG_EXECUTE_XOR_WRITE=y | 실행·쓰기 권한의 동시 부여 | 플랫폼 메모리 보호 기능과 실제 영역 속성을 확인했는가? |
도구에 표시된 FAIL을 바꾸기로 했다면 설정 조각을 수정한 뒤 제품 빌드를 다시 만들고 .config와 산출물을 재확인한다. 반대로 의도적으로 권장값과 다른 구성이 필요하면 해당 위협, 기능상의 이유, 대체 통제, 확인 시험을 남겨야 한다. hardenconfig 결과의 공백이나 개수만으로 이 결정을 자동화할 수 없다.
근거: v3.7.0 hardened.csv. 표의 ‘검토할 위험’과 ‘현장 조건’은 CSV 값을 바탕으로 한 편집상 해석이며 보드별 지원·효력을 검증한 결과가 아니다.
5. 설정 뒤에는 관측 가능한 제품 증거를 붙인다
같은 Kconfig 값이어도 보드 기능과 주변 부팅·통신 설계가 다르면 결과가 달라진다. 그래서 위협 모델에서 출발한 선택을 최종 이미지와 장치 시험에 연결해야 한다. 예컨대 Shell을 끈 빌드라면 .config의 값뿐 아니라 배포 이미지에서 어떤 관리 경로가 남는지 확인한다. 스택 보호를 고른 빌드라면 지원 아키텍처와 실기 실패 동작도 살핀다.
↔ 앞 단계의 증거를 다음 단계의 입력으로 넘기는 흐름입니다.
.config재현할 수 있는 빌드 조건| 주장하려는 내용 | 필요한 확인 예시 | 주의할 한계 |
|---|---|---|
| 생산 이미지에 진단 Shell이 없다 | 최종 .config, 빌드 산출물, 실제 입력 경로 점검 | 다른 원격 관리·디버그 경로는 별도 |
| 스택 오류가 격리·탐지된다 | 보드 지원 확인, 해당 보호의 활성값, 통제된 오류 시험 | 모든 메모리 오류를 탐지한다는 뜻 아님 |
| 권한 없는 요청은 거부된다 | 경계별 음성 시험과 오류·로그 관측 | 입력 검증·인증·키 관리도 별도 |
| 출시 후 취약점에 대응한다 | 영향 추적, 수정·업데이트·재시험 기록 | 출시 당시의 한 번의 결과로 대체 불가 |
6. 결과가 예상과 다르면 비교 지점을 먼저 좁힌다
FAIL 행이 보인다고 곧바로 취약점이 확정되는 것은 아니다. 반대로 출력이 비었다고 보안 검토가 끝난 것도 아니다. 다음 질문을 순서대로 확인하면 ‘권장값 차이’, ‘구성 의존 조건’, ‘실제 실행 경계’를 혼동하지 않는다.
| 관측 | 먼저 확인 | 다음 조치 |
|---|---|---|
| 예상한 심볼의 FAIL이 없다 | 같은 빌드 디렉터리인가, 심볼이 존재하고 보이는가? | 최종 .config와 의존 조건을 직접 확인 |
| FAIL이 있으나 값 변경이 불가 | 보드·아키텍처 의존 조건과 기능 필요성 | 대체 통제 또는 남는 위험 기록 |
| FAIL이 0개다 | CSV가 다루지 않는 노출·권한·업데이트 경로 | 위협 모델과 실기 시험 계속 수행 |
| 설정은 맞는데 실기에서 실패 | 정확한 이미지·보드·부팅 단계·관측 지점 | 지원 기능과 런타임 오류 경로 재검토 |
도구 출력 조건은 v3.7.0 구현에서 확인했다. 진단 절차는 그 범위를 바탕으로 만든 제품 검토 예시다.
7. User Mode와 TF-M은 다른 경계를 구현한다
보안 강화 작업은 권한 격리나 보안 실행 환경과 연결되지만, hardenconfig가 그 둘을 설정·검증하는 단일 스위치는 아니다. User Mode는 Zephyr 내부의 사용자 스레드, 시스템 호출, 커널 객체·메모리 접근을 다룬다. TF-M은 지원 플랫폼에서 보안·비보안 이미지와 PSA 서비스를 나누는 통합이다. 이 글은 어느 쪽의 세부 API를 재설명하기보다 두 기능을 포함한 제품의 보안 주장에 어떤 추가 증거가 필요한지 묻는다.
| 주제 | 핵심 질문 | 별도로 확인할 것 |
|---|---|---|
| 이 글의 보안 강화 | 위협과 개발·구성·시험 근거가 이어지는가? | 제품별 범위·시험·유지 절차 |
| Zephyr User Mode | 사용자 스레드가 어떤 메모리·커널 객체에 접근하나? | 지원 아키텍처, 객체 권한, 메모리 도메인, 거부 경로 |
| TF-M 통합 | 보안·비보안 실행 환경과 PSA 서비스 경계는 어디인가? | 보드 포트, 이미지·키·프로비저닝, 실제 서비스 동작 |
한 기능을 켠 뒤 보드에서 해당 경계를 검증했다고 해서 제품 전체의 보안 주장이 세워지는 것은 아니다. 따라서 User Mode나 TF-M을 사용하더라도 디버그 노출, 업데이트, 키 운영, 외부 입력의 위협은 남아 있다.
8. 고정 버전 근거와 확인하지 않은 것
본문의 명령과 출력 조건은 Zephyr v3.7.0 문서·태그 소스에 맞췄다. 특히 이 버전의 권장값 원본은 hardened.csv이며, 다른 릴리스의 데이터 형식·프로파일 설명을 섞지 않았다. 세 그림과 판단표는 원문 이미지를 복제하지 않은 자체 도식이다. 제품 보드 빌드, 하드웨어 보호 시험, 침투 시험, 인증 평가는 이 글의 검증 범위에 포함되지 않는다.