# 조직 및 운영 보안(OPS)

## 조직 및 운영 보안

> 우수한 보안 관행의 기초는 조직 내에서 시작됩니다.

## 보안 및 개인정보보호팀 구축 <a href="#create-a-team" id="create-a-team"></a>

> 전담 보안 및 개인정보보호팀을 구축하고 이 조직의 리더를 정하세요.
>
> * **보안팀 구축:**
>   * 최소 한 명의 직원이 보안, 개인 정보 보호 및 사고 대응을 담당하도록 합니다.
>   * 이 팀의 임무와 업무 범위를 정의합니다.
>   * 보안 관리자, 보안 엔지니어, 사고 관리자와 관련된 조직도 및 업무 설명을 수립합니다.
>   * 직원 또는 외부 계약직을 고용하여 이러한 역할을 충원합니다.
> * **SDL(보안 개발 수명 주기) 정의**: SDL은 다음과 같은 영역을 포괄해야 합니다.
>   * 제품 보안 요구사항
>   * 위험 분석 및 위협 모델링
>   * 애플리케이션 및 코드의 [정적 및 동적 분석](https://source.android.com/docs/security/test/fuzz-sanitize?hl=ko)
>   * 제품의 최종 보안 검토 프로세스
>   * 사고 대응
> * **조직 위험 평가**: 위험 평가를 마련하고 이러한 위험을 제거하거나 완화하기 위한 계획을 수립합니다.

## 빌드 인증 프로세스 <a href="#build-verification" id="build-verification"></a>

> 기존 내부 빌드 인증 및 승인 프로세스의 허점을 평가합니다.
>
> * 빌드 내 [PHA(잠재적으로 위험한 애플리케이션)](https://developers.google.com/android/play-protect/phacategories?hl=ko) 발생으로 이어질 수 있는 현재의 빌드 인증 프로세스의 모든 문제점을 파악합니다.
> * 사내 [AOSP](https://android.googlesource.com/) 패치의 경우에도 코드 검토 및 승인 프로세스가 마련되어 있는지 확인합니다.
> * 다음과 같은 영역에 제어 기능을 구현하여 빌드 무결성을 개선합니다.
>   * **변경사항 추적**: 소프트웨어 엔지니어를 추적하고 변경 로그를 유지합니다.
>   * **위험 평가**: 앱에서 사용하는 권한을 평가하고 코드 변경사항의 수동 검토를 요구합니다.
>   * **모니터링**: 권한 있는 코드에 대한 변경사항을 평가합니다.

## 소스 코드 변경 추적 <a href="#source-code-change-tracking" id="source-code-change-tracking"></a>

> 소스 코드 또는 서드 파티 앱/바이너리/SDK에 대한 의도하지 않은 수정을 모니터링합니다.
>
> * **파트너십 평가**: 다음 단계에 따라 기술 파트너와의 협업에 따른 위험을 평가합니다.
>   * 특정 공급업체와의 협업에 따른 위험을 평가하는 방법에 관한 기준을 수립합니다.
>   * 공급업체를 대상으로 사고를 어떻게 해결하고 보안 및 개인 정보 보호를 어떻게 관리할지 묻기 위한 양식을 작성합니다.
>   * 주기적인 감사로 상대의 주장을 검증합니다.
> * **변경사항 추적**: 어떤 회사와 직원이 소스 코드를 수정하고 주기적인 감사를 시행하는지 기록하여 적절한 변경사항만 적용되도록 합니다.
> * **기록 유지**: 어떤 회사가 서드 파티 바이너리를 빌드에 추가하는지 기록하고, 이러한 앱이 어떤 기능을 수행하고 어떤 데이터를 수집하는지를 문서화합니다.
> * **계획 업데이트**: 공급업체가 제품의 온전한 수명을 위한 소프트웨어 업데이트를 제공하도록 합니다. 예기치 못한 취약점을 해결해야 하는 경우 공급업체의 지원이 요구될 수 있습니다.

## 소스 코드 무결성 및 계보의 유효성 검사 <a href="#validate-source-code" id="validate-source-code"></a>

> ODM(원래의 기기 제조업체), OTA(무선 업데이트) 또는 이동통신사가 공급한 소스 코드를 확인하고 유효성을 검사합니다.
>
> * **인증서 서명 관리**
>   * HSM(하드웨어 보안 모듈) 또는 보안 클라우드 서비스에 키를 보관합니다 (공유하면 안 됨).
>   * 인증서 서명에 대한 액세스가 관리 및 감사되는지 확인합니다.
>   * 모든 코드 서명이 빌드 시스템에서 이루어지도록 합니다.
>   * 분실한 키를 취소합니다.
>   * 권장사항에 따라 키를 생성합니다.
> * **새 코드 분석** 보안 코드 분석 도구로 새로 추가된 코드를 테스트하여 새로운 취약점이 유입되지 않았는지 확인합니다. 또한 전체 기능을 분석하여 새로운 취약점의 수식을 감지합니다.
> * **게시 전 검토** 프로덕션에 게시하기 전에 소스 코드 및 서드 파티 앱에서 보안 취약점을 찾습니다. 예를 들면 다음과 같습니다.
>   * 앱에서 보안 통신을 사용하도록 요구합니다.
>   * 최소 권한의 원칙을 따르고 앱이 작동하기 위해 필요한 최소의 권한 모음을 부여합니다.
>   * 데이터가 보안 채널을 통해 저장 및 전송되도록 합니다.
>   * 서비스 종속 항목을 최신 상태로 유지합니다.
>   * SDK 및 오픈소스 라이브러리에 보안 패치를 적용합니다.

## 사고 대응 <a href="#incident-response" id="incident-response"></a>

> Android는 강력한 보안 커뮤니티가 문제를 찾는 데 기여할 수 있다고 믿습니다. 따라서 외부 당사자가 기기 관련 보안 문제를 문의할 수 있도록 방법을 마련하여 게시해야 합니다.
>
> * **연락처 설정**: <security@your-company.com>과 같은 이메일 주소나 제품과 관련된 잠재적인 보안 문제 신고 절차가 명확히 설명되어 있는 웹사이트를 만듭니다([예](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="<https://doc.skill.or.kr>" %}
NHN Cloud 정보 사이트&#x20;
{% endembed %}

{% embed url="<https://sul.skill.or.kr>" %}
보안 업데이트 정보 사이트&#x20;
{% endembed %}