# 조직 및 운영 보안(OPS) ## 조직 및 운영 보안 > 우수한 보안 관행의 기초는 조직 내에서 시작됩니다. ## 보안 및 개인정보보호팀 구축 > 전담 보안 및 개인정보보호팀을 구축하고 이 조직의 리더를 정하세요. > > * **보안팀 구축:** > * 최소 한 명의 직원이 보안, 개인 정보 보호 및 사고 대응을 담당하도록 합니다. > * 이 팀의 임무와 업무 범위를 정의합니다. > * 보안 관리자, 보안 엔지니어, 사고 관리자와 관련된 조직도 및 업무 설명을 수립합니다. > * 직원 또는 외부 계약직을 고용하여 이러한 역할을 충원합니다. > * **SDL(보안 개발 수명 주기) 정의**: SDL은 다음과 같은 영역을 포괄해야 합니다. > * 제품 보안 요구사항 > * 위험 분석 및 위협 모델링 > * 애플리케이션 및 코드의 [정적 및 동적 분석](https://source.android.com/docs/security/test/fuzz-sanitize?hl=ko) > * 제품의 최종 보안 검토 프로세스 > * 사고 대응 > * **조직 위험 평가**: 위험 평가를 마련하고 이러한 위험을 제거하거나 완화하기 위한 계획을 수립합니다. ## 빌드 인증 프로세스 > 기존 내부 빌드 인증 및 승인 프로세스의 허점을 평가합니다. > > * 빌드 내 [PHA(잠재적으로 위험한 애플리케이션)](https://developers.google.com/android/play-protect/phacategories?hl=ko) 발생으로 이어질 수 있는 현재의 빌드 인증 프로세스의 모든 문제점을 파악합니다. > * 사내 [AOSP](https://android.googlesource.com/) 패치의 경우에도 코드 검토 및 승인 프로세스가 마련되어 있는지 확인합니다. > * 다음과 같은 영역에 제어 기능을 구현하여 빌드 무결성을 개선합니다. > * **변경사항 추적**: 소프트웨어 엔지니어를 추적하고 변경 로그를 유지합니다. > * **위험 평가**: 앱에서 사용하는 권한을 평가하고 코드 변경사항의 수동 검토를 요구합니다. > * **모니터링**: 권한 있는 코드에 대한 변경사항을 평가합니다. ## 소스 코드 변경 추적 > 소스 코드 또는 서드 파티 앱/바이너리/SDK에 대한 의도하지 않은 수정을 모니터링합니다. > > * **파트너십 평가**: 다음 단계에 따라 기술 파트너와의 협업에 따른 위험을 평가합니다. > * 특정 공급업체와의 협업에 따른 위험을 평가하는 방법에 관한 기준을 수립합니다. > * 공급업체를 대상으로 사고를 어떻게 해결하고 보안 및 개인 정보 보호를 어떻게 관리할지 묻기 위한 양식을 작성합니다. > * 주기적인 감사로 상대의 주장을 검증합니다. > * **변경사항 추적**: 어떤 회사와 직원이 소스 코드를 수정하고 주기적인 감사를 시행하는지 기록하여 적절한 변경사항만 적용되도록 합니다. > * **기록 유지**: 어떤 회사가 서드 파티 바이너리를 빌드에 추가하는지 기록하고, 이러한 앱이 어떤 기능을 수행하고 어떤 데이터를 수집하는지를 문서화합니다. > * **계획 업데이트**: 공급업체가 제품의 온전한 수명을 위한 소프트웨어 업데이트를 제공하도록 합니다. 예기치 못한 취약점을 해결해야 하는 경우 공급업체의 지원이 요구될 수 있습니다. ## 소스 코드 무결성 및 계보의 유효성 검사 > ODM(원래의 기기 제조업체), OTA(무선 업데이트) 또는 이동통신사가 공급한 소스 코드를 확인하고 유효성을 검사합니다. > > * **인증서 서명 관리** > * HSM(하드웨어 보안 모듈) 또는 보안 클라우드 서비스에 키를 보관합니다 (공유하면 안 됨). > * 인증서 서명에 대한 액세스가 관리 및 감사되는지 확인합니다. > * 모든 코드 서명이 빌드 시스템에서 이루어지도록 합니다. > * 분실한 키를 취소합니다. > * 권장사항에 따라 키를 생성합니다. > * **새 코드 분석** 보안 코드 분석 도구로 새로 추가된 코드를 테스트하여 새로운 취약점이 유입되지 않았는지 확인합니다. 또한 전체 기능을 분석하여 새로운 취약점의 수식을 감지합니다. > * **게시 전 검토** 프로덕션에 게시하기 전에 소스 코드 및 서드 파티 앱에서 보안 취약점을 찾습니다. 예를 들면 다음과 같습니다. > * 앱에서 보안 통신을 사용하도록 요구합니다. > * 최소 권한의 원칙을 따르고 앱이 작동하기 위해 필요한 최소의 권한 모음을 부여합니다. > * 데이터가 보안 채널을 통해 저장 및 전송되도록 합니다. > * 서비스 종속 항목을 최신 상태로 유지합니다. > * SDK 및 오픈소스 라이브러리에 보안 패치를 적용합니다. ## 사고 대응 > Android는 강력한 보안 커뮤니티가 문제를 찾는 데 기여할 수 있다고 믿습니다. 따라서 외부 당사자가 기기 관련 보안 문제를 문의할 수 있도록 방법을 마련하여 게시해야 합니다. > > * **연락처 설정**: 과 같은 이메일 주소나 제품과 관련된 잠재적인 보안 문제 신고 절차가 명확히 설명되어 있는 웹사이트를 만듭니다([예](https://security.samsungmobile.com/securityReporting.smsb)). > * **취약점 포인트 제도(VRP) 수립**: 유효한 제출 내용에 대해서는 금전적 보상을 제공함으로써 외부 보안 연구자가 제품에 영향을 미치는 보안 취약점 보고서를 제출하도록 권장합니다([예](https://www.google.com/about/appsecurity/android-rewards/?hl=ko)). 심각도가 매우 높은 취약점의 경우 $5,000, 심각도가 높은 취약점의 경우 $2,500와 같이 업계에서 경쟁력 있는 수준의 보상을 제공하는 것이 좋습니다. > * **업스트림 프로젝트 변경에 참여**: 여러 기기 제조업체의 Android 플랫폼이나 기기에 영향을 미치는 보안 문제를 인지한 경우 [보안 버그 신고](https://g.co/AndroidSecurityReport)를 제출하여 Android 보안팀에 문의합니다. > * **우수 보안 관행 장려**: 기기와 관련된 서비스, 구성요소 및 코드를 제공하는 하드웨어 및 소프트웨어 공급업체의 보안 관행을 사전에 평가합니다. 공급업체에서 책임지고 우수한 보안 관행을 유지하도록 합니다. {% embed url="" %} NHN Cloud 정보 사이트 {% endembed %} {% embed url="" %} 보안 업데이트 정보 사이트 {% endembed %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ssv.skill.or.kr/best-practices/ops.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.