Meta 앱 개발

데이터 보안 요구 사항

다음 데이터 보안 요구 사항은 2023년 데이터 보안 평가에 해당합니다.

2024년 2월 이후에 받은 평가 버전의 경우 이 페이지를 참조하세요.

문제가 발생했습니다
이 동영상을 재생하는 중 문제가 발생했습니다.
더 알아보기

특정 유형의 Meta 플랫폼 데이터에 액세스할 권한이 있는 앱은 연례 데이터 보안 평가(DPA)를 완료해야 합니다. DPA는 개발자가 플랫폼 데이터의 사용, 공유 및 보안과 관련 있는 Meta 플랫폼 약관의 요구 사항을 충족하는지 확인하기 위해 설계되었습니다. DPA 설문지의 일부 내용은 데이터 보안 요구 사항이 나와 있는 플랫폼 약관 6에 중점을 두고 있습니다. 이 문서를 통해 Meta 플랫폼 약관에 정의된 데이터 보안 사용 및 처리와 관련된 기대, 요구 사항 및 관련 증거를 이해하시는 것이 좋습니다.

본 문서 마지막 부분에 있는 용어집에는 주요 용어 및 정의가 포함되어 있습니다.

데이터 프로토콜에서 더 많은 동영상 리소스를 확인해 보세요.

이 문서 전체에서 서버 측이라는 문구는 Amazon Web Services(AWS)와 같은 클라우드 호스트에서 실행되고 있거나, 공유 또는 전용 데이터 센터에서 개발자가 호스팅했거나, (이 둘의 조합인) 하이브리드인지 여부와 관계없이 조직에서 플랫폼 데이터를 처리하는 데 사용하는 백엔드 환경의 줄임말로 사용됩니다.

클라이언트 측 요구 사항은 브라우저, 모바일 기기, 데스크톱 및 노트북 컴퓨터의 앱, 사람들이 사용하는 기타 유형의 기기 내에서 플랫폼 데이터를 처리하는 것을 가리킵니다.

데이터 보안 질문에 대한 답변 준비

데이터 플로

앱 또는 시스템에서 플랫폼 데이터를 처리하는 방법을 보여주는 데이터 플로 다이어그램 또는 설명을 만들거나 업데이트(필요한 경우)합니다.

  1. 클라이언트 측 - 브라우저, 모바일 기기, 기타 지원되는 기기 유형을 비롯한 모든 클라이언트 소프트웨어를 포함합니다.
  2. 서버 측 - 모든 관련 서버 또는 클라우드 환경을 포함하고 다음을 식별합니다.
    1. 다음 경우의 플랫폼 데이터 관련 구성 요소:
      1. 플랫폼 데이터가 서버 환경에 들어오거나 서버 환경에서 나간 경우(예: 웹 리스너 및 REST API)
      2. 플랫폼 데이터가 영구적이거나 내구성이 뛰어난 스토리지(예: 데이터베이스, 디스크, 로그 파일)에 기록된 경우
    2. 다음의 예를 포함하는 호스팅 모델:
      1. 자체 호스팅 - 소유되거나 공유된 데이터 센터에서 실행 중인 조직의 자체 서버.
      2. IaaS(Infrastructure as a Service) - 예: AWS EC2, Microsoft Azure IaaS, Google Compute Engine.
      3. PaaS(Platform as a Service) - 예: AWS Elastic Beanstalk, Google App Engine, Force.com.
      4. BaaS(Backend as a Service) - 예: AWS Amplify, Azure Mobile Apps, Firebase, MongoDB Switch.
      5. 하이브리드 - 위 모델의 일부 조합.

마지막으로, 데이터 플로 다이어그램 또는 설명은 다음을 포함해야 합니다.

  1. 클라이언트 소프트웨어와 서버 소프트웨어 양쪽에서 Meta API 액세스 토큰이 생성되고 전송/저장/갱신되는 위치(시스템 설계에 적용되는 경우)
  2. 특히 개인의 이름, 이메일 주소, 성별, 생년월일 및 기타 사용자 데이터와 같은 개인 식별 정보(PII)를 중심으로 Meta의 API에서 플랫폼 데이터를 가져오는 방법
  3. 이 데이터를 사용, 저장, 전송하는 방법
  4. 플랫폼 데이터를 전송받을 모든 제4자

증거 준비

회원님은 회원님이 시행하는 데이터 보안 보호 조치에 관한 답변을 뒷받침하는 증거를 제출해야 할 수도 있습니다. 이 문서의 증거 가이드에서 허용되는 증거의 예를 참고하여 적절한 증거를 준비할 것을 추천합니다. 일반적인 문서 파일 유형과 스크린샷 및 화면 녹화가 허용됩니다. 파일이 비밀번호로 보호되지 않도록 하세요. 여러 개의 파일을 각각 최대 2GB까지 업로드할 수 있습니다. .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip 및 .zipx가 허용됩니다.

제출하기 전에 반드시 증거에서 민감한 데이터를 삭제하세요.

증거의 유형

데이터 보안 보호 조치에 관한 증거를 업로드하도록 요청받는 앱의 경우, Meta에서는 두 가지 서로 다른 유형의 문서를 요구합니다.

  1. 정책 또는 절차 증거 - [이 보호 조치]의 데이터 보안 접근 방식을 설명하는 정책 또는 절차 문서
  2. 시행 증거 - 특정한 보호 조치를 어떻게 시행했는지 보여주는 시스템 또는 앱의 증거(예: 도구 구성 또는 화면 캡처)

정책 또는 절차 증거

정책 또는 절차 증거(관리 권한이라고도 함)는 특정 데이터 보안 보호 조치의 접근 방식을 설명하는 서면으로 작성된 문서입니다. 내부 정책집의 발췌본, 내부 wiki 페이지의 일부 또는 전체, 기존 문서가 없는 경우 접근 방식을 설명하는 데 사용할 새로 작성된 문서 등 다양한 형태의 문서가 이 증거로 사용될 수 있습니다. 어떤 경우든 업로드하는 정책 또는 절차 증거는 특정한 보호 조치의 접근 방식이 Meta 요구 사항과 어떤 관련이 있는지 명확히 설명해야 합니다. Meta의 보안 검토와 관련이 있고 이에 필요한 정책 또는 발언만 제공하거나, 주관식 질문 상자를 사용하여 연결된 각 질문을 통해 Meta 검토자를 관련 섹션으로 안내해주세요.

시행 증거

시행 증거는 스크린샷 또는 화면 녹화를 통해 정책 또는 절차를 실제로 어떻게 시행했는지를 직접 보여줍니다. 개발자별로 구성이 다르므로 모든 시나리오의 예를 제공할 수는 없습니다. 그렇긴 하지만, 시행 증거는 저희가 제공한 증거와 최대한 동일한 수준의 상세 정보를 보여줘야 합니다.

증거의 완전성

저희는 특정한 데이터 보안 보호 조치의 시행을 포괄적으로 보여줄 시행 증거를 준비하는 것이 지나치게 부담스러울 수 있다는 것을 알고 있습니다. 이를 염두에 두고, 회원님은 주의를 기울여 증거에서 민감한 정보를 삭제한 후 다음 가이드에 따른 증거를 제출해야 합니다.

  1. 정책 또는 절차 증거는 Meta의 요구 사항을 명백히 충족하거나 뛰어넘는 것이어야 합니다.
    1. Meta는 특정한 보호 조치에 관한 Meta의 요구 사항과 일치하는 진술에 대한 정책 또는 절차 증거를 검토합니다.
    2. 회원님은 문서에 주석을 달아 관련된 섹션을 강조 표시해야 합니다.
    3. 예를 들어 플랫폼 데이터가 전송되는 모든 네트워크 연결에 대한 TLS 1.2 이상 암호화 사용 설정 보호 조치와 관련하여, 허용되는 증거는 다음과 같은 명확한 진술이 적힌 문서를 포함합니다.
      1. Meta의 플랫폼 데이터는 암호화되지 않은 형식으로 신뢰할 수 없는 네트워크를 통해 전송되어서는 안 됩니다.
      2. 플랫폼 데이터를 수신하거나 반환하는 모든 웹 리스너(예: 인터넷 연결 로드 밸런서)는 TLS 1.2가 사용 설정되도록 구성됩니다.
      3. 플랫폼 데이터를 수신하거나 반환하는 모든 웹 리스너는 다음이 비활성화되도록 구성됩니다. SSL v2, SSL v3, TLS 1.0, TLS 1.1
  2. 시행 증거는 각 정책 또는 절차 시행의 예를 하나 이상 보여줘야 합니다.
      1. 회원님은 각 보호 조치를 어떻게 시행했는지 보여주는 문서, 스크린샷 또는 도구 구성을 하나 이상 업로드해야 합니다.
      2. Meta는 시행 증거를 검토하여 정책 또는 절차 증거와 일치하는지 확인합니다.
      3. 예를 들어 플랫폼 데이터가 전송되는 모든 네트워크 연결에 대한 TLS 1.2 이상 암호화 사용 설정 보호 조치와 관련하여, 허용되는 증거는 정책 또는 절차에 따라 구성된 웹 도메인 중 하나의 Qualys SSL 테스트 보고서를 포함합니다.

증거에서 삭제해야 하는 민감한 데이터

다음 값이 읽을 수 있는(삭제되지 않은) 형태로 포함된 증거는 제출하지 마세요. 스크린샷에 이미지 편집기를 사용하는 경우, 값 위에 검은색 상자를 덮어씌우세요. PDF 편집기를 사용하는 경우, 텍스트를 보존하면서 단순히 레이어를 추가하는 대신 값을 실제로 삭제하는 도구를 사용하여 반드시 텍스트를 삭제해야 합니다(예: Apple의 Preview 앱의 삭제 도구).

  • 건강 데이터
  • 금융 데이터
  • IP 주소
  • 비밀번호, 자격 증명 및 액세스 토큰
  • 암호화 키
  • 실제 주소
  • 직간접적으로 개인을 식별할 수 있는 자연인(비즈니스 또는 기타 기업 조직을 포함하지 않음), 직원 또는 기타 관계자에 대한 개인 식별 정보(PII). 예:
    • 이름
    • 이메일 주소
    • 사용자 ID
    • 생년월일
    • 위치 데이터
    • 건강 데이터
    • 문화적, 사회적, 정치적 정체성
    • 구체적인 증거의 맥락에서 다른 방식으로 개인을 식별할 수 있는 데이터
  • 취약점의 자세한 재현 단계(예: 침투 테스트 보고서의 단계)
  • 만 14세 미만 어린이가 제공했거나 만 14세 미만 어린이에 대한 것이라고 개발자가 알고 있거나 알고 있다고 합리적으로 의심되는 데이터

유휴 상태 암호화로 서버 측에 저장된 플랫폼 데이터 보호

질문: 클라우드, 서버 또는 데이터 센터 환경에 저장된 모든 플랫폼 데이터에 유휴 상태 암호화를 실행하나요?

의도

유휴 상태 암호화는 별도의 암호 해독 키 없이는 데이터를 해독할 수 없도록 만들어 플랫폼 데이터를 보호합니다. 따라서 데이터를 무단 읽기 액세스로부터 추가로 보호합니다.

  • 모든 앱 사용자와 관련된 플랫폼 데이터가 집중되는 경향이 있는 서버 또는 클라우드 환경에서, 유휴 상태 암호화는 데이터 유출의 위험을 줄여줍니다.
  • 예를 들어 유휴 상태 암호화는 프로덕션 데이터베이스 자체만큼 긴밀하게 보호되지는 않을 수도 있는, 데이터베이스 백업에 대한 무단 액세스 같은 위협으로부터 데이터를 보호합니다.

요구 사항의 요약

서버 측에서 플랫폼 데이터를 저장하는 경우:

  • 데이터를 반드시 다음 방식으로 보호해야 합니다.

  • 사용된 암호화 유형별:
    • 앱 수준(예: 데이터베이스의 소프트웨어 암호화/암호 해독용 열) 또는 전체 디스크 암호화 모두 괜찮습니다.
    • 저희는 업계 표준 암호화(예: AES, BitLocker, Blowfish, TDES, RSA) 사용을 권장하지만, 특정 알고리즘이나 키 길이를 요구하지는 않습니다.

개발자가 서버 측에 플랫폼 데이터를 저장하지 않는 경우, 이 요구 사항이 적용되지 않습니다.

특별한 경우

IaaS, 셀프 호스팅 또는 하이브리드 호스팅을 사용한 서버 측 저장

IaaS 호스팅(예: AWS EC2, Microsoft Azure IaaS, Google Compute Engine), 자체 호스팅 또는 하이브리드 방식을 사용하여 플랫폼 데이터를 저장하는 경우에는 이 질문이 적용됩니다.

SaaS, PaaS 또는 BaaS 제품을 사용한 서버 측 저장

하지만 기타 특별한 백엔드 호스팅 모델이 사용되는 경우가 있습니다.

(IaaS, 셀프 호스팅 또는 하이브리드 호스팅을 사용하지 않고) 이 특별한 백엔드 호스팅 모델을 통해서만 플랫폼 데이터를 저장하는 경우 이 질문이 적용되지 않습니다. 대신 데이터 보안 평가의 서비스 제공업체 섹션에 이 관계를 설명해야 합니다.

  • BaaS - 예: AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase, MongoDB Switch
  • PaaS - 예: AWS Elastic Beanstalk, Google App Engine, Force.com
  • SaaS - 예: MailChimp 또는 Salesforce

Meta API를 사용한 서버 측 저장

Meta API를 통해서만 플랫폼 데이터를 저장하는 경우(예: 인스턴트 게임 SDK에서 player.setDataAsync() 사용) 이 질문이 적용되지 않습니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

시행 증거의 예

AWS RDS

AWS RDS - 유휴 상태 암호화는 AWS RDS에서 구성 가능하므로, 개발자가 이 보호 조치를 적용하도록 구성 옵션을 설정해야 합니다.

플랫폼 데이터가 포함된 전형적인 RDS 인스턴스의 경우 AWS CLI 도구를 사용하여 StorageEncrypted 구성을 가져오세요.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

AWS DynamoDB는 기본적으로 유휴 상태 암호화됩니다. 다음 명령어를 사용하여 테이블의 유휴 상태 암호화 구성을 가져올 수 있습니다.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB는 유휴 상태 암호화를 적용하도록 구성해야 합니다. 플랫폼 데이터가 포함된 전형적인 클러스터의 경우 다음 명령어를 사용하여 StorageEncrypted 구성을 가져오세요.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

AWS S3 버킷은 버킷 내에 생성된 모든 객체에 유휴 상태 암호화를 적용하도록 구성할 수 있습니다. 다음 명령어를 사용하여 버킷을 나열하고 기본 버킷 암호화의 구성을 가져오세요.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

조직의 서비스 사용과 관련된 Azure의 유휴 상태 암호화에 관한 Microsoft의 문서를 참고하세요.

Google Cloud Platform

Google Cloud Platform의 유휴 상태 암호화에 관한 Google의 문서를 참고하세요.

허용되는 대체 보호 조치

서버 측 환경에서 유휴 상태 암호화를 시행하지 않는 경우, 허용되는 대체 방법으로 플랫폼 데이터를 보호할 수 있습니다. 이 경우 다음을 설명해야 합니다.

  1. 플랫폼 데이터의 민감도 - 특정 플랫폼 데이터의 보관은 위험이 더 낮거나 더 높은 것으로 간주됩니다. 서버 측에 저장되는 특정 플랫폼 데이터 사용자 특성을 조사해야 합니다.
  2. 구체적인 피해의 가능성을 줄이기 위해 적용되는 관리 기능
    1. 플랫폼 데이터가 포함된 네트워크의 손상을 방지하기 위한 관리 기능
    2. 플랫폼 데이터에 액세스할 수 있는 앱/시스템의 손상을 방지하기 위한 관리 기능
    3. 플랫폼 데이터가 포함된 물리적 저장 미디어(예: 연결 해제된 네트워크 저장 장치)의 손실을 방지하기 위한 관리 기능
    4. 플랫폼 데이터가 포함된 물리적 저장 미디어(예: 연결 해제된 네트워크 저장 장치)의 손실을 방지하기 위한 관리 기능
    5. 플랫폼 데이터의 백업이 포함된 스토리지의 백업본에 대한 무단 액세스를 방지하기 위한 관리 기능
  3. 증거의 강도 - 이러한 보호 조치가 독립적인 감사인에 의해 평가되었는지 확인해야 합니다(예: SOC2 감사의 일환으로).

단체의 기기 및 이동식 미디어에 저장된 플랫폼 데이터의 손실 방지

질문: 구체적으로 단체 및 개인 기기에 저장된 데이터에 관한 질문: 이러한 기기에 저장된 모든 플랫폼 데이터에 대해, 유휴 상태의 암호화를 시행하거나 데이터 손실의 위험을 줄이기 위한 정책 및 규칙을 활용하고 있나요?

의도

개발자가 직원 노트북 또는 이동식 스토리지(예: USB 드라이브)와 같은 기기에 플랫폼 데이터를 저장할 수 있도록 허용하면, 기기가 분실되거나 도난 당할 경우 이 데이터는 무단으로 이용될 위험이 높습니다. 개발자는 이 위험을 제한하기 위한 조치를 취해야 합니다.

요구 사항의 요약

  • 무단 플랫폼 데이터 액세스의 위험을 줄이기 위해, 개발자는 단체의 기기(예: 노트북) 및 이동식 미디어의 플랫폼 데이터와 관련된 기술 관리 기능(선호함) 또는 일반 관리 기능(선호하지 않지만 허용됨)을 가지고 있어야 합니다.

    • 기술 관리 기능 - 기술 관리 기능의 예: 1) 관리되는 기기만 회사 네트워크에 연결할 수 있도록 허용, 2) 관리되는 기기에서 전체 디스크 암호화 실행(예: BitLocker), 3) 이동식 미디어가 관리되는 기기(예: USB 드라이브)에 연결되지 않도록 차단, 4) 관리되는 기기에 데이터 손실 방지(DLP) 기술 사용
    • 일반 관리 기능 - 일반 관리 기능의 예에는 단체 및 개인 기기의 허용되는 플랫폼 데이터 취급 방법에 대한 서면 정책 문서 및 연례 교육이 포함됩니다.

이 요구 사항은 서버 측에서 플랫폼 데이터를 처리하는지 여부와 관계없이 적용됩니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

a) 기술적 관리 기능(예: 디스크 암호화) 또는 b) 노트북, 휴대폰 등 단체의 기기에 저장되는 플랫폼 데이터의 데이터 손실의 위험을 줄이기 위한 규칙/정책 중 하나 또는 둘 다를 사용할 수 있습니다.

기술적 관리 기능에는 다음과 같은 기능이 포함됩니다.

  • 관리되지 않는 기기가 프로덕션 네트워크와 같이 민감한 서비스에 연결되지 않도록 차단
  • 관리되는 기기에 디스크 암호화 시행(예: Windows의 BitLocker 또는 Mac의 FileVault를 통해 시행)
  • 관리되는 기기에서 이동식 미디어(예: USB 드라이브)를 사용하지 못하도록 차단
  • 관리되는 기기에서 DLP 소프트웨어를 사용하여 플랫폼 데이터의 부적절한 처리 차단(예: 이메일 첨부 파일로 전송)

규칙/정책에는 다음이 포함됩니다.

  • 일반적으로 허용되거나 허용되지 않는 데이터, 특히 플랫폼 데이터 처리 방법을 설명하는 문서
  • 단체 구성원이 가이드라인을 인식하도록 하는 메커니즘(예: 고용 조건의 일부로 계약상 합의, 교육, 이메일을 통한 주기적 알림)

증거 예

단체에서 자체 데이터 분류 기준에 따라 Meta의 플랫폼 데이터를 "비공개 데이터"로 분류합니다. 이 단체에서는 데이터 처리 가이드라인을 작성하여 모든 직원이 의무적으로 이 정책을 이해하고 준수하도록 했습니다.

전송 중 암호화를 사용하여 네트워크를 통해 전송되는 플랫폼 데이터 보호

질문: 플랫폼 데이터가 전송되는 공개 네트워크를 통과하거나, 연결하거나, 지나가는 모든 네트워크 연결에 대해 보안 프로토콜 TLS 1.2 이상을 사용하나요? 또한 암호화되지 않은 형식(예: HTTP, FTP)의 공개 네트워크를 통해 플랫폼 데이터를 전송하지 않으며 보안 프로토콜 SSL v2 및 SSL v3가 사용되지 않도록 조치하고 있나요?

의도

인터넷상에서 전송되는 플랫폼 데이터는 네트워크 트래픽을 관찰할 수 있는 사람이라면 누구나 액세스할 수 있습니다. 따라서 권한이 없는 사람이 데이터를 읽을 수 없도록 암호화를 통해 보호해야 합니다.

  • 전송 중 암호화는 플랫폼 데이터가 신뢰할 수 없는 네트워크(예: 인터넷)를 통해 전송될 때 송신 및 수신 기기를 제외하고는 해독할 수 없도록 만들어 플랫폼 데이터를 보호합니다.
  • 즉, 전송의 중간에 있는 사람은 네트워크 트래픽을 볼 수는 있어도 플랫폼 데이터를 읽을 수는 없습니다(이를 중간자 공격이라고도 합니다).
  • TLS는 브라우저에서 은행과 같은 웹사이트의 통신을 보호하기 위해 사용하는 기술로, 가장 일반적인 전송 중 암호화 형태입니다.

요구 사항의 요약

서버 측에서 플랫폼 데이터를 처리하는지 여부:

  • 플랫폼 데이터는 암호화되지 않은 형식으로 신뢰할 수 없는 네트워크를 통해 전송되어서는 안 됩니다.
  • 플랫폼 데이터를 수신하거나 반환하는 모든 웹 리스너(예: 인터넷 연결 로드 밸런서)에 대해 다음을 수행해야 합니다.
    • TLS 1.2 이상 사용 설정
    • SSL v2 및 SSL v3 비활성화
  • TLS 1.0 및 TLS 1.1은 TLS 1.2 이상을 지원하지 않는 클라이언트 기기와의 호환성을 위해서만 사용할 수 있습니다.
  • VPC(Virtual Private Cloud)와 같은 사설 네트워크 내에서 플랫폼 데이터를 전체적으로 전송할 경우 전송 중 암호화가 권장되지만 필수는 아닙니다.

아래 표에는 다양한 전송 유형에 대한 전송 중 암호화 정책이 요약되어 있습니다.

전송 유형전송 중 암호화 정책

최종 사용자 기기(휴대폰, PC, 태블릿 등)와 서버 또는 클라우드 인프라 간의 연결

  • 호환 기기를 위해 TLS 1.2 이상을 사용 설정해야 합니다.
  • 이전 기기와의 호환을 위해서는 TLS 1.0 및 1.1을 사용 설정할 수도 있습니다.

서버 또는 클라우드 인프라와 원격 서버, 클라우드 인프라 또는 제4자 서비스 간의 연결

TLS 1.2 이상을 사용해야 합니다.

비공개 데이터 센터, 서버 또는 클라우드 인프라에 완전히 포함되는 구성 요소 간의 연결

비공개 클라우드 네트워크에 완전히 포함되는 플랫폼 데이터 전송에는 TLS 암호화가 권장되지만 필수는 아닙니다.

Meta와 모든 기기, 서버 또는 클라우드 인프라 간의 연결

데이터 보안 평가 범위 외 - 이러한 전송의 경우 Meta가 TLS 정책을 관리합니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요. 웹 리스너 중 하나의 구성을 입증하는 시행 증거를 생성하는 간단한 방법은 Qualys SSL Server Test 도구를 사용하는 것입니다.

  • 비표준 포트에서 실행되는 웹 리스너를 포함하여 동일하게 구성된 웹 리스너 중 하나 이상에 대해 Qualys SSL Server Test 도구를 실행합니다.
  • 결과가 Qualys 웹사이트에 추가되지 않도록 '보드에 결과를 표시하지 않음' 옵션을 선택합니다. 전체 테스트 결과 페이지를 PDF로 인쇄합니다. 플랫폼 데이터를 주고받을 모든 다양한 TLS 구성의 웹 리스너에 대해 위의 단계를 반복합니다.

시행 증거의 예

Qualys SSL Server Test 도구의 출력 예시입니다. 지원되는 SSL/TLS 버전이 요약된 구성 섹션의 빨간색 주석에 유의하세요. 참고: 이 예에는 처음 두 페이지만 포함되어 있지만 회원님은 전체 테스트 출력을 해야 합니다.

허용되는 대체 보호 조치

TLS 이외에 다양한 유형의 암호화를 사용하여 전송 중인 플랫폼 데이터를 보호할 수 있습니다. 해당 암호화 방식이 TLS와 동등한 수준의 보호를 제공한다면 가능합니다. 이 경우 암호화에 대한 세부 정보를 제출해야 합니다. 해당 정보는 Meta에서 다음을 검토하는 데 사용됩니다.

  • 대칭/비대칭 암호화 여부
  • 암호화 알고리즘(예: AES, BitLocker, TDES, RSA)
  • 최소 키 길이

앱과 시스템에 취약점 및 보안 문제가 있는지 테스트하세요

질문: 최소한 12개월마다 앱과 시스템에 취약점 및 보안 문제가 있는지 테스트하시나요? (예를 들어 수동 침투 테스트를 수행하시나요?)

의도

개발자는 취약점 및 보안 문제가 있는지 테스트하여 사전에 발견하고 보안 사고가 발생하기 전에 이상적으로 이를 방지할 수 있도록 해야 합니다.

  • 자신이 구성하고 운영하는 앱/시스템을 통해 작성한 소프트웨어로 플랫폼 데이터를 처리하기 위해 Meta 플랫폼을 사용하는 앱 개발자
  • 소프트웨어 및 시스템 구성에는 악의적인 사람들에게 악용될 수 있는 보안 취약점이 포함되어 있을 수 있으며, 이는 플랫폼 데이터에 대한 무단 액세스로 이어질 수 있습니다.

요구 사항의 요약

모든 개발자에게 적용되는 사항:

  • 다음 중 하나를 수행하여 플랫폼 데이터를 처리하는 데 사용되는 소프트웨어에 보안 취약점이 있는지 테스트했어야 합니다.
    • 앱/시스템 침투 테스트
    • 소프트웨어의 취약점 스캔/정적 분석
  • 테스트 결과는 해결되지 않은 중대하거나 매우 심각한 취약점이 없다는 것을 보여줘야 합니다.
  • 테스트는 최근 12개월 이내에 완료되었어야 합니다.

서버 측 플랫폼 데이터를 처리하는 개발자를 위한 추가 요구 사항:

  • 다음 중 하나를 수행하여 서버 측 소프트웨어에 보안 취약점이 있는지 특별히 테스트했어야 합니다.
    • 앱/시스템 침투 테스트
    • 취약점 스캔/정적 분석 또한 클라우드 호스팅 공급자를 이용 중인 경우 클라우드 구성에 보안 문제가 있는지 테스트했어야 합니다. 이 요구 사항은 호스팅 접근 방식(예: BaaS, PaaS, IaaS, 자체 호스팅 또는 하이브리드)에 상관없이 적용됩니다.

조직에서 개발 프로세스에 SAST를 추가하려는 경우 NIST에 오픈 소스 및 커머스 도구 목록이 유지 관리됩니다. 이 목록은 도구를 선택하는 데 유용한 시작점이 될 수 있습니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

조직이 클라우드 또는 서버 환경에서 플랫폼 데이터를 처리하는 경우:

  • 침투 테스트 또는 SAST 도구 실행을 완료했다는 증거를 제출합니다. 증거는 다음을 포함해야 합니다.
    • 테스트 범위에 대한 진술
    • 테스트 완료 날짜 – 날짜는 최근 12개월 이내에 해당되어야 합니다.
    • 테스트 중에 발견된 취약점 목록 또는 요약 해당 요약 또는 목록은 심각성 카테고리 분류(예: 중대함, 높음, 중간, 낮음, 심각하지는 않으나 참고)를 포함해야 합니다. 통상적으로, 해결되지 않은 중대하거나 높은 심각성의 취약점이 없어야 합니다.

플랫폼 데이터를 처리하는 데 사용하는 인터넷 액세스 가능 클라우드 또는 서버 소프트웨어(예: 웹 및 모바일 클라이언트에서 사용되는 REST API)는 이 테스트 범위에 포함되어야 허용됩니다.

  • 해당하는 경우(즉, AWS, GCP, Azure 또는 이와 유사한 클라우드 호스트를 이용 중인 경우) 클라우드 구성 검토를 수행했다는 증거(예: NCC Scout Suite, AWS Config 또는 이와 유사한 도구 실행 출력 결과)를 제출합니다. 이 경우에 해당되지 않는 조직의 경우 클라우드 구성 검토가 해당 사항이 아닌 이유를 설명하는 문서를 증거 제출에 포함합니다.
  • 제출하기 전에 증거에서 세부 취약점 재현 단계와 같은 민감한 정보를 삭제합니다.

조직이 클라우드 또는 서버 환경에서 플랫폼 데이터를 처리하지 않는 경우:

  • 침투 테스트 또는 SAST 도구 실행을 완료했다는 증거를 제출합니다. 증거는 다음을 포함해야 합니다.
    • 테스트 범위에 대한 진술
    • 테스트 완료 날짜 – 날짜는 최근 12개월 이내에 해당되어야 합니다.
    • 테스트 중에 발견된 취약점 목록 또는 요약 해당 요약 또는 목록은 심각성 카테고리 분류(예: 중대함, 높음, 중간, 낮음, 심각하지는 않으나 참고)를 포함해야 합니다. 통상적으로, 해결되지 않은 중대하거나 높은 심각성의 취약점이 없어야 합니다.
  • 제출하기 전에 증거에서 세부 취약점 재현 단계와 같은 민감한 정보를 삭제합니다.

증거 예

침투 테스트 - 조직에서 Meta API와 통합되고 플랫폼 데이터를 처리하는 서버 측 실행 소프트웨어에 대한 침투 테스트를 의뢰합니다. 테스트 회사는 테스트를 완료하고 아래와 같은 요약 내용을 생성합니다. 테스트가 수행된 날짜(최근 12개월 이내여야 함)를 강조하여 보여주는 빨간색 주석에 유의하세요. 테스트 또는 재테스트(해당하는 경우) 결과에는 해결되지 않은 중대한/높은 심각성 발견 사항이 요약되어 있습니다. 보고서를 제출하기 전에 민감한 정보(특히, 세부 취약점 재현 단계)를 삭제하세요.

정적 분석 - SAST 도구와 같은 다른 접근 방식을 사용하는 경우 SAST 실행 날짜와 각 결과의 유형과 심각성/중요도를 포함하는 결과 목록을 포괄하는 문서로 결과를 내보냅니다.

클라우드 구성 검토

개발자는 클라우드 공급자(이 경우 AWS)에 대한 기본 규정을 적용한 NCC Scout Suite를 사용하여 클라우드 구성에 취약점 및 보안 문제가 있는지 검토합니다. 이 도구는 자세한 실행 결과가 포함된 JSON 파일을 출력합니다. 이 예에는 개발자가 검토하고 해결해야 하는 '위험' 심각성으로 플래그 지정된 많은 문제가 있습니다.

원시 NCC Scout Suite JSON 파일에는 업로드해서는 안 되는 클라우드 환경에 대한 세부 정보가 포함되어 있습니다. 대신에 응답을 필터링하여 심각도별 결과 수를 보여줍니다.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}


Amazon Web Services 규정을 적용하여 개발자를 위한 클라우드 구성 검토를 수행하는 다른 접근 방식.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

허용되는 대체 보호 조치

기능성 VDP(Vulnerability Disclosure Program)를 운영 중인 경우(예: BugCrowd 또는 HackerOne 플랫폼을 사용 중인 경우) 펜 테스트 또는 취약점 스캔 대신 이 기능을 대체 보호 조치로 제공할 수 있습니다. 이를 입증하기 위해 다음과 같은 증거를 제출해야 합니다.

  • 플랫폼 데이터 처리 방식과 관련된 VDP 범위에 제외 사항이 없다는 증거
  • 최근 12개월 이내에 실제로 진행 중인 취약점 연구 및 보고가 있다는 증거(통상적으로 한 달에 1개 이상의 유효한 취약점 보고서를 뜻함)
  • CVSS 3.1 등을 사용하여 제출된 (유효한) 취약점에 심각성 점수를 할당했다는 증거
  • 제출 날짜로부터 합당한 기간(통상적으로 90일 이내) 후 취약점이 해결되었다는 증거

이 경우 증거는 다음을 포함해야 합니다.

  • 플랫폼 데이터를 처리하는 데 사용된 소프트웨어와의 상호 관계 및 범위에 대한 진술
  • 최근 12개월 동안 프로그램에 실제로 취약점이 제출된 보고서 보고서는 취약점 제목, 제출 날짜, 해결 날짜(해결된 경우) 및 심각성 카테고리/점수를 포함해야 합니다.

Meta 앱 시크릿 코드 및 API 액세스 토큰 보호

질문: Meta API 액세스 토큰 및 앱 시크릿 코드가 다음 두 가지 방법으로 모두 보호되나요?

  1. Meta API 액세스 토큰을 현재 앱 및 사용자 이외에 다른 앱 및 사용자가 액세스할 수 있는 클라이언트 기기에 저장하지 않습니다.
  2. 클라우드, 서버 또는 데이터 센터 환경에 저장된 경우 별도의 키 관리 서비스(KMS)를 사용하는 데이터 볼트(예: Hashicorp의 Vault)를 사용합니다.

의도

앱 시크릿 코드 및 액세스 토큰은 Meta AP가 허용할 조치에 대한 결정을 내리는 방식을 보호하는 데 필수적입니다. 권한이 없는 사람이 이러한 자격 증명에 대한 액세스 권한을 확보할 경우, 실제 개발자를 사칭하여 Meta의 API를 호출하고 앱에 부여된 모든 작업을 실행할 수 있습니다(예: Meta API에서 앱 사용자에 대한 데이터 읽기).

  • 회원님은 Meta 플랫폼 사용의 일부로서 민감한 자격 증명에 액세스할 수 있습니다. 다음에서 자세히 확인해보세요.
    • 액세스 토큰 - 사람들이 앱에 권한을 부여할 때 소프트웨어는 후속 API 호출에서 사용되는 액세스 토큰이라는 자격 증명을 얻습니다.
    • 앱 시크릿 코드 - Meta는 단체 내에서 신뢰할 수 있는 사람(예: 앱 관리자)만 이 시크릿 코드에 액세스할 수 있으리라는 기대하에 개발자와 시크릿 코드를 공유합니다.
  • 이 민감한 자격 증명을 읽을 수 있는 사람은 권한이 없어도 이 자격 증명을 사용하여 회원님인 것처럼 Meta API를 호출하고(토큰 사칭이라고도 함) 플랫폼 데이터에 무단으로 액세스할 수 있습니다.
  • 따라서 이 자격 증명에 무단 액세스하지 못하도록 보호하여 사칭을 방지해야 합니다.

요구 사항의 요약

액세스 토큰

  1. 클라이언트 기기에서 - 다른 사용자나 프로세스가 읽을 수 있도록 Meta 액세스 토큰을 기록하지 않아야 합니다.
  2. 서버 측 - 서버 측에서 Meta 액세스 토큰을 처리하거나 저장하는 경우 이 액세스 토큰은 다음 요구 사항을 충족해야 합니다.
    1. 별도의 키 관리 서비스(KMS)를 사용하는 데이터 볼트(예: Hashicorp의 Vault)를 사용하여 보호하고 앱에서만 복호화 키에 액세스할 수 있도록 제한해야 합니다.
    2. 로그 파일에 기록해서는 안 됩니다.

앱 시크릿 코드 - 다음 둘 중 하나가 참이어야 합니다.

  1. 절대로 보안 서버 환경 외부로 앱 시크릿 코드를 노출하지 않아야 합니다(예: 브라우저 또는 모바일 앱에 대한 네트워크 호출에서 앱 시크릿 코드를 반환하지 않으며 시크릿 코드가 모바일 또는 네이티브/데스크톱 클라이언트에 배포되는 코드에 포함되지 않음).
  2. 또는 Meta API에서 더 이상 앱 시크릿 코드가 포함된 API 호출을 신뢰하지 않도록 네이티브/데스크톱 유형으로 앱을 구성했어야 합니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

앱이 서버 측에서 Meta 액세스 토큰을 처리하는 경우 Meta API 액세스 토큰 및 앱 시크릿 코드를 보호하기 위한 정책에 대한 문서를 포함하고, 회원님이 취하는 보호 조치(예: 볼트의 사용, 암호화된 형식으로 저장된 값 표시, 앱 시크릿 코드 증거를 요구하는 앱의 구성)를 보여주는 증거를 포함하세요.

제출하는 증거에 시크릿 코드 또는 액세스 토큰의 일반 텍스트 값은 포함하지 않아야(즉, 삭제해야) 합니다.

증거 예

한 단체에서 AWS Secrets Manager를 사용하여 Meta 앱 시크릿 코드 등 민감한 데이터를 안전하게 저장합니다.



한 단체에서는 API 호출에 앱 시크릿 코드 증거를 요구하도록 Meta 앱을 구성했습니다.

허용되는 대체 보호 조치

  1. 서버 측에 저장된 액세스 토큰을 데이터 볼트 또는 앱 수준 암호화를 통해 보호하지 않는 경우 다음 조치를 취할 수 있습니다.
    1. 앱에서만 키에 액세스할 수 있는 볼트 또는 앱 암호화를 이용하여 앱 시크릿 코드를 보호할 수 있습니다.
    2. Meta에 대한 모든 API 호출에 앱 시크릿 코드 증거를 요구하도록 앱을 구성할 수 있습니다.
  2. 위의 접근 방식 #1을 실행할 수 없는 경우(즉, 일부 필수 API 호출을 차단할 수 있어 앱 시크릿 코드 증거를 요구할 수 없는 경우), Meta는 저장된 액세스 토큰의 오용에 따른 위험과 비교하여 액세스 토큰 무단 사용의 위험을 제한하기 위해 회원님이 활용하는 다른 관리 기능을 고려합니다.

사고 대응 계획을 보유하고 사고 대응 시스템 및 프로세스를 테스트하세요

질문: 최소 12개월마다 보안 사고(예: 데이터 유출 또는 사이버 공격)에 대응하기 위해 사용하는 시스템과 프로세스를 테스트하시나요?

의도

보안 사고는 모든 회사에서 수시로 발생할 수 있으므로 조직에서는 사고를 방지하고, 관계자와 소통하고, 사고로부터 복구하고 교훈을 얻기 위해 누가 무엇을 해야 하는지 미리 계획해야 합니다.

  • 보안 사고가 발생한 경우, 무엇을 해야 하는지 교육받은 사람들로 구성된 팀과 함께 준비된 계획이나 플레이북이 있으면 사고 기간을 단축하고 궁극적으로 플랫폼 데이터의 노출을 제한할 수 있습니다.
  • 여러 조직에서 다양한 수준의 정교한 사고 대응 시스템을 보유하고 있지만, 최소한 주요 활동(감지, 대응, 복구, 검토)과 역할 및 책임이 할당된 담당자 명단이 포함된 기본 계획이 요구됩니다.

요구 사항의 요약

개발자는 반드시

  • Meta의 최소 기준을 충족하는 사고 대응 계획을 보유해야 합니다.
  • 이 문서는 (최소한) 다음을 포함해야만 합니다. (1) 역할 및 책임, (2) 감지, (3) 관련 법적 의무에 따른 대응(예: 관련 감독 기관과 데이터 주체에게 데이터 침해 알림) 및 복구 단계, (4) 사고 후 검토 절차
  • 계획이 최근에(최근 12개월 이내에) 테스트되었으며 계획에 포함된 모든 담당자가 참여했다는 문서화된 증거

이 요구 사항은 서버 측에서 플랫폼 데이터를 처리하는지 여부와 관계없이 적용됩니다.

증거 가이드

증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

  • 사고 대응 계획(하나 이상의 문서)을 제출합니다. 이 계획에는 역할 및 책임, 감지, 대응 및 복구, 사고 후 검토 등의 주제가 포함되어야 합니다.
  • 최근 12개월 이내에 계획을 테스트했다는 증거를 제출하세요. 이 증거는 다양한 형식일 수 있지만 다음 사항을 포함해야 합니다.
    • 시나리오 설명(예: 랜섬웨어 공격에 대비한 모의 훈련)
    • 테스트가 수행된 날짜
    • 각 참가자의 역할
    • 계획의 역할 및 책임 섹션 명단에 있는 담당자가 참여하지 않은 경우, 불참을 정당화하는 개별 사유
  • 제출하기 전에 이 증거에서 민감한 정보(예: 개인의 이름, 이메일 주소와 같은 PII)를 삭제하세요. 증거 예

사고 대응 계획

개발자가 이 템플릿에 기반하여 포괄적인 사고 대응 계획을 수립했습니다. 이 이미지에는 목차만 나와 있지만 아래에 전체 템플릿에 대한 링크가 있습니다.

Counteractive 사고 대응 계획 템플릿(docx 형식) 전문 보기

사고 대응 테스트

개발자가 모의 훈련을 통해 사고 대응 계획에 대한 테스트를 실시하고 이 템플릿에 기반하여 결과를 문서화했습니다.

여기에는 처음 두 페이지만 포함되어 있지만, 실제 제출 시엔 전체 문서를 제출해야 합니다.

원격 액세스를 위한 다단계 인증 요구

질문: 클라우드 또는 서버 환경에 연결하거나 회원님이 Meta의 플랫폼 데이터를 저장하는 시스템을 배포, 유지, 모니터링, 운영하기 위해 사용하는 서비스에 액세스할 수 있는 모든 계정에 원격 액세스를 위한 다단계 인증을 요구하나요?

의도

악의적인 사람들이 기밀 데이터에 대한 액세스 권한을 얻기 위해 사용하는 일반적인 방법은 먼저 개발자가 앱/시스템을 빌드 또는 운영하기 위해 사용하는 도구에 대한 액세스 권한을 얻는 것입니다. 비밀번호로만 보호되는 계정을 해킹하는 데 사용되는 정교한 도구가 존재합니다. 다단계 인증은 보안을 강화하여 이러한 위험으로부터 보호합니다.

  • 소프트웨어 개발자는 다양한 도구를 사용하여 앱/시스템을 빌드, 배포 및 관리합니다
  • 이러한 도구는 일반적으로 인터넷을 통해 원격으로 사용합니다(예: 직원이 재택근무를 하면서 새 소프트웨어 기능을 출시하거나 클라우드 구성을 업데이트함).
  • 단일 단계 인증(사용자 이름과 비밀번호)을 사용하여 보호되는 도구는 계정 탈취 공격에 매우 취약합니다. 예를 들어 공격자가 도구를 사용하여 한 도구에서 누출된 사용자 이름과 비밀번호의 조합으로 다른 도구에 대한 액세스 권한을 얻으려고 시도할 수 있습니다
  • 다단계 인증은 로그인 시 비밀번호 외에 추가 단계(예: 인증 앱에서 생성된 코드)를 요구하여 이러한 공격을 차단합니다

요구 사항의 요약

단체의 플랫폼 데이터 처리와 관련하여 다음 도구의 원격 액세스는 다단계 인증으로 보호해야 합니다(즉, 단순히 비밀번호만으로 보호해서는 안 됨).

  • 코드/구성 변경 사항을 앱/시스템에 배포하기 위해 사용되는 도구
  • 클라우드 또는 서버 환경에 대한 관리 액세스 권한(해당하는 경우)

구체적으로 다음의 경우 MFA 또는 허용되는 대체 보호 조치가 요구됩니다.

  • 협업/커뮤니케이션 도구 - 예: 비즈니스 이메일 또는 Slack
  • 코드 저장소 - 예: GitHub 또는 앱/시스템의 코드/구성 변경 사항을 추적하기 위해 사용되는 다른 도구
  • 다음과 같이 서버 측에서 플랫폼 데이터를 처리하는 경우에도 요구됩니다.
    • 소프트웨어 배포 도구 - 클라우드/서버 환경에 코드를 배포하기 위해 사용되는 도구, 예: Jenkins 또는 다른 지속적 통합/지속적 배포(CI/CD) 도구
    • 관리 도구 - 클라우드 또는 서버 환경을 관리/모니터링하기 위해 사용되는 포털 또는 기타 액세스 권한
    • 서버에 대한 원격 액세스 권한 - SSH, 원격 데스크톱 또는 서버 측에서 실행되는 서버에 원격으로 로그인하기 위해 사용되는 유사한 도구

MFA 시행 관련하여 다음 사항을 확인하세요.

  • SMS로 전송하는 코드에 인증 앱 또는 하드웨어(예: YubiKey)를 사용하는 것이 좋습니다
  • 하지만 단체에서는 모든 MFA 시행을 활용할 수 있습니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

  • 시행 증거는 위에 나열된 환경에 적용할 수 있는 도구에서 MFA가 시행된다는 것을 보여줘야 합니다(예: 협업 도구, 코드 저장소, 클라우드/서버 배포, 클라우드/서버 관리 포털, 클라우드/서버 원격 액세스)
  • 시행은 구성에 따라 다릅니다.
    • 예를 들어 SSO 제공업체를 사용하는 경우 단체의 전역 구성을 보여주는 스크린샷 또는 앱별 구성을 보여주는 스크린샷을 사용할 수 있습니다.
    • SSO 제공업체가 없는 경우에는 특정 도구 구성의 스크린샷을 사용할 수 있습니다.
  • 모든 경우, MFA가 사용하도록 설정된 계정의 예시뿐 아니라 모든 사용자에 대해 MFA가 사용하도록 설정되었다는 증거가 필요합니다.

증거 예

AzureAD

단체에서 AzureAD를 SSO 솔루션으로 사용합니다. 이 정책에서는 다단계 인증을 요구합니다.

그런 다음 이 정책은 정책이 적용되는 클라우드 앱으로 매핑됩니다. 이 접근 방식을 사용하면 증거를 통해 선택된 항목 섹션 전체를 볼 수 있어 어느 클라우드 앱에서 MFA를 요구하는지 명확히 알 수 있습니다.



Okta

이 규칙에서는 모든 로그인에 MFA를 요구합니다.



AWS IAM

MFA 구성을 허용하지만 MFA가 없을 경우 다른 작업을 금지하는 AWS IAM 정책의 예입니다.



GitHub

단체에서 단체 내 모든 사람에게 MFA를 요구하도록 GitHub 인증을 구성했습니다.

허용되는 대체 보호 조치

  • MFA가 시행되지 않는 단체 내에 존재하는 모든 유형의 원격 액세스에 대해 다음 접근 방식 중 하나 이상을 사용하여 계정 탈취를 방지하고 있는지 설명해야 합니다.
    • 강력한 비밀번호 요구 사항 - 예: 최소 비밀번호 복잡성, 사전 단어 금지, 이전에 침해된 것으로 알려진 비밀번호 금지
    • 인증 백오프 - 동일한 소스의 로그인 시도 실패 간의 대기 시간을 점차적으로 연장하는 도구의 사용
    • 자동 잠금 - 예: 로그인 시도가 10회 실패한 후 계정 로그인을 자동으로 차단하는 메커니즘

사용자 계정을 유지 관리하기 위한 시스템 보유

질문: 계정을 유지 관리(액세스 및 권한을 할당, 취소, 검토)하기 위한 시스템이 있나요?

의도

계정을 무단으로 사용하여 플랫폼 데이터에 대한 액세스 권한을 얻지 못하도록 하기 위해서는 적절한 계정 관리 시스템을 보유하고 있어야 합니다. 특히 개발자는 더 이상 필요하지 않은 리소스나 시스템에 대한 액세스 권한을 취소해야 합니다.

  • 계정은 사람들에게 시스템, 데이터, 관리 기능에 대한 액세스 권한을 부여하기 위한 기본 관리 단위입니다.
  • 계정에는 특정한 작업을 실행할 수 있는 권한이 부여됩니다. 좋은 업무 관행은 계정이 필요로 하는 최소한의 권한만 부여하는 것입니다. 이를 최소 권한의 원칙이라고 합니다.
  • 누군가 조직을 떠나면 다음 몇 가지 이유에서 그 사람의 사용자 계정을 신속히 비활성화하는 것이 중요합니다.
    • (1) 그 사람(즉, 전직 직원)의 액세스를 방지하기 위해
    • (2) 권한이 없는 사람이 발견되지 않고 몰래 계정을 사용할 가능성을 줄이기 위해 예를 들어 악의적인 사람이 소셜 엔지니어링을 사용하여 IT 지원 센터에서 계정의 비밀번호를 재설정하게 할 수도 있습니다. 이 계정이 현재 직원의 계정인 경우 해당 직원이 로그인할 수 없다고 신고할 가능성이 크지만, 계정이 아직 활성 상태이더라도 조직을 떠난 직원의 계정인 경우 발견될 가능성이 적습니다.
  • 이를 염두에 두고, 조직에서는 체계적인 방법으로 계정을 관리하고, 권한 또는 특별 권한을 부여하고, 더 이상 필요하지 않은 액세스 권한을 취소해야 합니다.

요구 사항의 요약

  • 다음과 같은 각 도구/시스템/앱의 계정을 관리하기 위한 도구 또는 프로세스를 가지고 있어야 합니다.
    • 서로 커뮤니케이션하기 위해 사용되는 도구/시스템/앱. 예: Slack 또는 비즈니스 이메일
    • 소프트웨어를 출시하기 위해 사용되는 도구/시스템/앱. 예: 코드 저장소
    • 시스템 관리 및 운영(플랫폼 데이터 처리에 해당하는 경우)
  • 정기적으로(즉, 최소한 12개월마다) 액세스 권한 부여 상태를 검토하고 다음과 같은 경우 액세스 권한을 취소하는 프로세스를 가지고 있어야 합니다. (1) 더 이상 필요하지 않음, (2) 더 이상 사용되지 않음
  • 누군가 조직을 떠날 때 이러한 도구에 대한 액세스 권한을 신속하게 취소할 수 있는 프로세스도 가지고 있어야 합니다.
  • Meta는 다음 사항을 요구하지 않습니다.
    • 특정 도구의 사용 – 개발자는 디렉터리 제품(예: Google Cloud identity, Microsoft Azure Active Directory), 클라우드 제품(예: AWS Identity and Access Management (IAM)) 또는 정기적으로 업데이트되는 스프레드시트를 사용할 수 있습니다.
    • 다양한 액세스 유형 전반에서 계정을 관리하기 위한 단일의 통합된 도구의 존재.

이 요구 사항은 서버 측에서 플랫폼 데이터를 처리하는지 여부와 관계없이 적용됩니다.

증거 가이드

증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

  • 정책/절차 - 계정 관리 관행을 다룬 서면으로 기록된 정책 및 절차 문서를 제공합니다. 이 문서에는 계정 생성 및 권한 부여 절차, 최소 비밀번호 복잡성, 계정 폐쇄 정책, MFA 정책, 계정 초기화 절차, 비활성 기간 경과 시와 조직 퇴사 시(예: 직원이 사직하거나 해고된 경우)의 액세스 권한 취소 절차를 포함하시기 바랍니다.
  • 시행 증거 - 계정 관리를 위해 다음 도구 또는 프로세스 중 하나 이상이 시행된 증거를 제공합니다(또는 환경에 적합하지 않음을 표시). (1) 비즈니스 이메일 및 협업 도구, (2) 코드 저장소, (3) 클라우드/서버 배포 도구, (4) 클라우드/서버 관리 포털, (5) 클라우드/서버 원격 로그인(예: SSH 또는 원격 데스크톱). 대표적인 개별 도구 또는 프로세스의 경우 다음을 입증하는 증거를 포함합니다.
    • 조직을 떠난 사람의 해당 도구 액세스 권한이 취소됨(예: 사용자 계정을 현재 조직 멤버의 권한 데이터와 비교하는 조정 보고서)
    • 일정 기간 사용되지 않은 액세스 권한이 취소됨(예: 대표적인 활성 사용자 계정 소유자의 최종 액세스 날짜가 최근 90일(최대 비활성 기간이 3개월인 경우) 이내인지 보여주는 보고서)

증거 예

정책/절차 - 개발자가 액세스 권한을 부여, 검토 및 취소하는 절차가 포함된 액세스 수명 주기 관리 표준을 생성했습니다.

시행 예 - 퇴사한 직원에 대한 액세스 권한 취소

개발자는 Workday를 인사 관리(HR) 데이터(현재 고용 상태 포함)에 대한 권한 있는 출처로 사용합니다. 이 개발자는 Google Cloud Identity를 사용자 계정 관리와 정보 시스템 및 도구에 대한 액세스 권한 부여를 위한 ID 공급자(IdP)로 사용합니다.

개발자는 최신(예: 최근 12개월 이내) 조정 보고서를 실행하여 현재 직원에 대한 Workday 보고서에 따라 Google Cloud Identity에 현재 직원이 아닌 사람의 활성 사용자 계정이 존재하지 않음을 확인했다는 보고서를 제출하여 퇴사한 직원에 대한 액세스 권한을 취소했다는 증거를 제출합니다.

시행 예 - 더 이상 사용되지 않는 액세스 권한 취소

개발자는 Google Cloud Identity를 사용자 계정 관리와 정보 시스템 및 도구에 대한 액세스 권한 부여를 위한 ID 공급자(IdP)로 사용합니다.

개발자는 마지막 로그인이 지정된 기간보다 오래된 활성 사용자 계정이 없다는 것을 입증하기 위해 마지막 로그인 순으로 정렬된 사용자 디렉터리 증거를 제출하여 더 이상 사용되지 않는(즉, 최근 6개월 이내에 로그인하지 않은) 액세스 권한을 취소했다는 증거를 제출합니다.

시행 예 - GitHub(코드 저장소)

개발자는 ID 관리와 정보 시스템 및 도구에 대한 액세스 권한 부여를 위해 SSO(Single Sign On) 도구를 사용합니다. 개발자는 SSO 인증을 요구하도록 구성된 GitHub를 보유합니다.

최신 버전의 소프트웨어 유지

질문: 서버, 가상 시스템, 배포, 라이브러리, 패키지, 바이러스 백신 소프트웨어 등 시스템 코드와 환경을 지속적으로 업데이트하기 위한 시스템을 보유하고 있나요?

의도

소프트웨어 구성 요소는 보안 취약점을 해결하기 위해 규칙적으로 업데이트 및 패치되며 궁극적으로 이러한 구성 요소는 사용이 종료되며 더 이상 지원되지 않습니다. 이러한 구성 요소를 패키징하거나 사용하는 개발자는 알려진 취약점과 함께 소프트웨어를 실행하는 일이 없도록 최신 상태를 유지해야 합니다.

  • 앱 개발자는 다양한 제3자 소프트웨어를 사용하여 플랫폼 데이터를 처리하는 앱/시스템을 실행합니다
  • 예를 들어 개발자는 다음 항목의 일부 또는 모두를 사용합니다.
    • 라이브러리, SDK, 패키지 - 개발자는 이 항목을 자신의 맞춤 코드와 함께 패키징하여 앱을 빌드합니다.
    • 가상 시스템 이미지, 앱 컨테이너 및 운영 체제 - 앱은 가상화와 같은 서비스와 네트워크 및 스토리지에 대한 액세스 권한을 제공하는 하나 이상의 이러한 컨테이너에서 실행됩니다.
    • 브라우저, 운영 체제 및 직원/공동 작업자가 사용하는 다른 앱 - 개발자가 시스템을 빌드하고 실행하기 위해 사용하는 모바일 기기 및 노트북 컴퓨터에서 실행되는 소프트웨어
  • 보안 취약점은 일반적으로 이러한 구성 요소에서 발견되며, 이에 따라 패치가 릴리스됩니다
  • 그런 다음 패치에 의해 해결된 취약점은 공개 데이터베이스에 심각성 등급(낮음, 중간, 높음, 중대함)과 함께 공개됩니다
  • 따라서, Meta의 플랫폼을 사용하는 개발자는 다음과 같이 체계적인 방법으로 패치를 관리해야 합니다
    • 앱/시스템과 관련이 있는 패치 식별
    • 노출을 기반으로 긴급도 우선순위 지정
    • 지속적인 비즈니스 활동으로 패치 적용

요구 사항의 요약

다음 소프트웨어 구성 요소의 경우(해당하는 경우), 정의되고 반복 가능한 방법으로 보안 취약점을 해결하기 위해 사용할 수 있는 패치를 식별하고, 위험을 기반으로 우선순위를 지정하고, 지속적인 활동으로 패치를 적용해야 합니다.

  1. 클라우드 또는 서버 환경에서 사용되는 라이브러리, SDK, 패키지, 앱 컨테이너 및 운영 체제
  2. 클라이언트 기기(예: 모바일 앱 내)에서 사용되는 라이브러리, SDK, 패키지
  3. 멤버가 앱/시스템을 빌드하고 운영하기 위해 사용하는 운영 체제 및 앱(예: 직원의 노트북에서 실행되는 운영 체제 및 브라우저)

Meta는 이러한 활동에 특정한 도구를 사용하도록 요구하지 않습니다. 조직에서 여러 유형의 소프트웨어를 최신 상태로 유지하기 위해 다양한 접근 방식을 사용하는 것이 일반적입니다(예: 앱과 함께 패키징된 라이브러리, 직원 노트북을 위한 운영 체제 업데이트).

이 요구 사항은 호스팅 방식(예: BaaS, PaaS, IaaS, 셀프 호스팅 또는 하이브리드)에 관계없이 적용되지만, 최신 상태로 유지해야 하는 구성 요소 세트는 호스팅 방식에 따라 다릅니다.


아래 다이어그램은 다양한 아키텍처 유형에 대해 패치가 요구되는 부분을 보여줍니다.

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

먼저 환경에서 라이브러리, SDK, 패키지, 가상 머신 이미지, 앱 컨테이너, 운영 체제, 직원/공동 작업자가 사용하는 기타 앱 등 범위 내 유형의 소프트웨어를 식별합니다.

다음 활동에 사용하는 하나 이상의 도구가 있을 수 있습니다.

  • 인벤토리 - 스크린샷을 통한 문서 또는 궁극적으로 패치해야 하는 범위 내 라이브러리, 패키지, SDK, 컨테이너, 앱 서버, 운영 체제의 리스트를 나타내는 도구 또는 프로세스가 존재한다는 문서. 소프트웨어 유형(예: 클라우드 앱, 클라이언트 기기, 직원 기기)을 나타내는 인벤토리가 있어야 합니다.
  • 이용 가능한 소프트웨어 패치 식별 - 인벤토리와 관련된 보안 패치를 식별할 수 있는 도구 또는 프로세스가 있어야 합니다.
  • 우선 순위 지정 - 관련 패치에 우선 순위를 지정할 수 있는 도구 또는 프로세스(예: Jira 티켓, GitHub 이슈, 추적 스프레드시트)가 있어야 합니다.
    • 패치
    • 스크린샷을 통한 문서 또는 관련 패치를 식별하고 우선순위를 지정한 후, 다양한 대상에 공개되었음을 보여주는 문서.
  • 해결 시간 및 수명 종료(EOL) 소프트웨어의 사용에 관한 정책을 포함하세요.

증거 예

Snyk for a NodeJS 앱 - 한 개발자가 Synk 명령줄 인터페이스(CLI)를 사용하여 보안 취약점으로 알려져 있는 패키징된 제3자 종속성을 식별하고 해당 취약점의 심각도를 기반으로 우선순위를 지정합니다.



NPM Audit

한 개발자가 NPM Audit를 사용하여 Node 앱에서 사용되는 종속성에서 취약점을 찾습니다. 아래의 예 이미지는 패치해야 하는 여러 개의 높은 심각도 취약점을 보여줍니다.



Trivy

한 개발자가 Trivy를 사용하여 시스템 이미지에서 취약점을 찾습니다. 아래의 예 이미지는 이 이미지에 포함된 라이브러리에서 패치해야 하는 높은 심각도 취약점을 보여줍니다.



Windows Server Update Services(WSUS)

한 개발자가 Windows Server Update Services(WSUS)를 사용하여 여러 대의 서버와 PC/노트북을 관리합니다. 아래의 예 이미지는 Windows 업데이트를 검토, 승인, 배포할 수 있는 WSUS 도구의 관리 보기를 보여줍니다.

플랫폼 데이터에 대한 액세스를 로깅하고 플랫폼 데이터를 전송 및 저장하는 위치를 추적하는 시스템 보유

의도

신뢰할 수 있는 로그 파일이 없으면 개발자가 플랫폼 데이터에 대한 무단 액세스를 감지하기가 어렵거나 불가능합니다.

  • 감사 로그를 사용하면 단체에서 특정 사용자가 플랫폼 데이터가 포함된 데이터베이스 테이블에 대해 쿼리를 실행하는 등 이벤트가 발생한 사실을 기록할 수 있습니다.
  • 그런 다음 이 로그가 보안 사고가 확인된 후 의심스러운 활동 또는 법의학 분석을 기반으로 자동화된 알림을 트리거하는 것과 같은 프로세스를 지원할 수 있습니다.

요구 사항의 요약

서버 측에서 플랫폼 데이터를 처리하는 경우, 해당 환경 내에서 다음 요구 사항을 충족해야 합니다.

  • 주요 이벤트를 기록하는 감사 로그를 유지해야 합니다(예: 플랫폼 데이터 액세스, 격상된 권한으로 계정 사용, 감사 로그 구성 변경).
  • 감사 로그는 중앙 저장소에 통합하고 변경 또는 삭제되지 않도록 보호해야 합니다.

증거 가이드

증거를 업로드해야 하는 경우, 증거에 다음과 같은 내용을 포함해야 합니다.

  • 회원님은 시스템 전체를 보여주고 플랫폼 데이터를 저장하는 서비스를 지정하고 제4자 서비스로의 예상되는 전송을 포함하여 데이터의 출입 지점을 보여주는 최신 데이터 플로 다이어그램을 활용하는 등의 방식으로 현재 플랫폼 데이터를 저장, 액세스, 전송하는 방법을 이해하고 있습니다
  • 회원님은 위/변조가 어려운 감사 로그를 보유하고 있습니다
  • 플랫폼 데이터의 액세스에 관련된 이벤트는 로그에 캡처됩니다

플랫폼 데이터 전송 및 플랫폼 데이터가 시스템을 나갈 수 있는 주요 지점(예: 제3자, 공개 엔드포인트)을 모니터링하세요

의도

플랫폼 데이터를 처리되는 방식을 이해한 다음 실제 처리를 모니터링하는 것은 조직에서 플랫폼 데이터가 의도된 목적으로만 사용되는지 확인하는 중요한 방법입니다.

  • 개발자는 플랫폼 데이터가 저장되고, 네트워크를 통해 전송되고, 백업(다른 위치에 복제될 수 있음)에 기록되는 방식의 최신 상황을 항상 파악하고 있어야 합니다.
  • 예를 들어 모니터링을 통해 플랫폼 데이터가 예기치 못한 방식으로 전송 중이거나 적합한 전송 중 암호화가 되지 않은 채 네트워크를 통해 전송 중인 상황을 파악하여 적절한 조치를 취할 수 있습니다.

요구 사항의 요약

서버 측에서 플랫폼 데이터를 처리하는 경우, 해당 서버 환경 내에서 다음 요구 사항을 충족해야 합니다.

  • 플랫폼 데이터가 저장 및 처리되고 네트워크 간에 전송되는 과정을 보여주는 정확한 데이터 플로 다이어그램을 유지 관리
  • 시스템 외부로의 플랫폼 데이터 전송에 대한 모니터링을 구성(예: 자동 모니터링 제품을 통한 감사 로그)
  • 가능하다면, 예기치 못한 플랫폼 데이터 전송이 발생할 경우 알림을 생성하여 신속하게 검토할 수 있게 하는 모니터링 시스템을 구성(아래 요구 사항 참조 - 로그 및 기타 보안 이벤트를 모니터링하고 비정상적이거나 보안과 관련된 이벤트에 대한 알림을 생성하기 위한 자동 시스템 보유)

증거 가이드

이 보호 조치에 대한 증거를 제출해야 하는 경우 증거 준비의 안내에 따라 정책/절차 및 시행 증거를 모두 준비하세요.

다음에 대한 증거를 제공해야 합니다.

  • 회원님은 시스템 전체를 보여주고 플랫폼 데이터를 저장하는 서비스를 지정하고 제4자 서비스로의 예상되는 전송을 포함하여 데이터의 출입 지점을 보여주는 최신 데이터 플로 다이어그램을 활용하는 등의 방식으로 현재 플랫폼 데이터를 저장, 액세스, 전송하는 방법을 이해하고 있습니다
  • 위/변조가 어려운 감사 로그를 구현함
  • 플랫폼 데이터 전송 관련 이벤트가 로그에 기록됨(이벤트에는 조치를 취한 시간, 조치를 취한 사용자 또는 앱의 ID, 소스 및 목적지가 포함되어야 합니다)

로그 및 기타 보안 이벤트를 모니터링하기 위한 자동 시스템을 운영하고 비정상적이거나 보안과 관련된 이벤트에 대해 알림을 생성하는 방법

의도

사람이 인터넷에 연결 가능한 최신 시스템에서 예기치 않은 동작을 검토하고 식별하는 것은 비현실적인 일입니다. 대신, 로그 파일과 기타 신호를 수집하여 사람의 추가 조사가 필요한 경보를 울릴 수 있는 도구가 존재합니다.

요구 사항의 요약

서버 측에서 플랫폼 데이터를 처리하는 경우, 해당 서버 환경 내에서 다음 요구 사항을 충족해야 합니다.

  • 로그 파일과 기타 이벤트를 수집하고 문제가 발생하면 경보를 울리는 규칙을 설정할 수 있는 도구 및 사람들(예: 대기 중인 보안 조사관)에게 경보를 보내기 위한 시스템이 있어야 합니다.
  • 관련 신호(예: 웹 액세스 로그, 인증 시도, 사용자가 승격된 권한으로 취한 조치)를 도구로 가져와야 합니다.
  • 시간이 경과함에 따라, 신호와 노이즈 간의 균형(예: 너무 많은 허위 경보를 방지하고 조사를 보증하는 이벤트를 무시하지 않음)을 맞추기 위한 규칙을 조정 및 미세 조정해야 합니다.

증거 가이드

개발자는 보통 Security Information and Event Management(SIEM) 도구를 이 목적으로 사용합니다. 예:

  • McAfee Enterprise Security Manager
  • SolarWinds Security Event Manager
  • Splunk Enterprise Security
  • Sumo Logic

관련 신호 소스가 선택한 도구에 전송되고, 트리거 또는 알람이 구성되고, 알람이 후속 조치를 담당하는 직원에게 전달되고, 마지막으로 알람을 주기적으로(예: 월간 검토 또는 업데이트 주기를 통해) 조정하는 프로세스가 있다는 증거를 제공해야 합니다.

용어집

A

제3자 - 위험 관리 용어에서 제3자는 Meta 플랫폼의 개발자를 말합니다(자사(제1자)는 Meta 자체를 의미하고, 제2자는 Meta 제품을 사용하는 사람을 의미합니다).

제4자 - 위험 관리 용어에서 제4자는 개발자가 자신들의 비즈니스를 가능하게 하는 서비스를 제공받기 위해 이용하는 회사를 말합니다(자사(제1자)는 Meta를 의미하고, 제2자는 Meta 사용자를 의미하고, 제3자는 Meta 플랫폼의 개발자를 의미합니다). 액세스 토큰 - 소프트웨어에서 일부 작업(예: 사용자 프로필에서 데이터 읽기)을 수행하기 위해 API를 호출하는 데 사용되는 자격 증명(예: 비밀번호)입니다.

Amazon Web Services(AWS) - Amazon의 클라우드 컴퓨팅 서비스 제품군

앱 범위 ID(ASID) - 개인이 앱을 사용하기로 선택할 때 Meta에서 생성되는 고유한 식별자입니다. 단일 사용자가 두 개의 앱을 사용하는 경우 각 앱에서 서로 다른 ASID를 가지므로, ASID는 앱들 간에 데이터 세트를 사용자와 관련짓기 더욱 어렵게 만들어 사용자의 개인정보 보호를 개선하는 데 도움이 됩니다.

앱 시크릿 코드 - Meta가 앱 대시보드를 통해 개발자에게 제공하는 공유 암호입니다. 앱 시크릿 코드를 소유하면 소프트웨어에 그래프 API를 통해 일부 작업을 수행할 권한이 부여되므로 개발자는 권한 없는 당사자가 앱 시크릿 코드에 접근하지 못하도록 주의해야 합니다.

앱 도용 - 악의적인 사용자가 앱의 잘못된 구성이나 취약점(예: 웹 앱의 소프트웨어 취약점)을 통해 조직의 내부 네트워크에 무단으로 액세스할 수 있는 경우를 앱 도용이라고 합니다. 앱 도용을 방어하려면 앱 침투 테스트를 실행합니다. 네트워크 도용도 참조하세요.

앱 컨테이너 - 앱이 다양한 유형의 서버(예: Linux 또는 Windows Server와 같은 다양한 운영 체제를 실행하는 서버)에서 실행되도록 컨테이너에는 소프트웨어 코드 및 관련 종속성이 포함되어 있습니다. 개발자는 앱을 포함하는 컨테이너 이미지를 생성합니다. 앱 컨테이너 엔진 또는 런타임은 컨테이너 이미지를 호스팅(실행)합니다.

앱 암호화 - 앱에서 자체적으로 암호화 및 해독 작업을 수행하여 데이터를 보호하는 방법입니다. 반대로 전송 계층 보안(TLS)은 앱에서 원격 서버에 보안 연결을 설정할 때(예: HTTPS 사용) 전송 중인 데이터를 원활하게 암호화하고, 클라우드 제공업체는 유휴 상태의 데이터를 투명하게 암호화하는 서비스를 제공합니다.

앱 프로그래밍 인터페이스(API) - 이를 이용하면 두 컴퓨터가 네트워크를 통해 서로 대화할 수 있습니다. 예를 들어 모바일 앱이 중앙 집중식 일기 예보 시스템에서 특정 위치의 오늘의 날씨를 가져옵니다.

앱 시크릿 코드 증명 - 개발자가 앱 시크릿 코드를 소유하고 있음을 증명하는 매개변수(앱 시크릿 코드 증명)를 생성하는 Meta에 대한 API 호출을 추가적으로 보호합니다. 앱 시크릿 코드 증명은 앱 시크릿 코드와 액세스 토큰에 기반하는 해시 함수(일방향 함수라고도 함)의 결과물입니다. 그래프 API 호출 중에 앱 시크릿 코드 증명을 요구하도록 앱을 구성하면 추가적인 앱 시크릿 코드 증명 매개변수 없이 액세스 토큰을 사용할 수 없으므로 사용자 액세스 토큰 유출로 인한 잠재적 피해를 줄일 수 있습니다.

B

BaaS(Backend as a Service) - 개발자가 프론트엔드(즉, 앱에서 사용자가 상호 작용하는 부분)를 구축하는 데 집중할 수 있도록 앱 개발자를 위한 서버 측 기능 제품군을 제공하는 클라우드 컴퓨팅 방식입니다. BaaS 솔루션은 PaaS와 비슷하며, 거기다 사용자 인증과 모바일 푸시 알림 같은 서비스를 추가합니다. 예를 들어 인기 있는 BaaS 제품은 다음과 같습니다. AWS Amplify, Azure Mobile Apps, Firebase, MongoDB Switch.

C

암호문 - 암호화된 데이터의 동의어인 암호문은 어떠한 암호화 알고리즘을 거쳐 읽을 수 없게 만들어진 데이터를 가리키는 명칭입니다. 암호문의 반대말은 평문입니다.

클라이언트 측 - 사람들은 일반적으로 브라우저에서 웹사이트를 열거나 휴대폰 또는 태블릿에서 모바일 앱을 실행하여 인터넷 액세스 가능 서비스와 상호 작용합니다. 이때 이러한 브라우저 또는 모바일 앱을 로컬 클라이언트 또는 클라이언트 측이라고 합니다. 클라이언트는 인터넷을 통해 원격 컴퓨터(서버)에 요청을 합니다.

클라우드 컴퓨팅 - 조직에서 물리적 환경(즉, 서버 랙 및 네트워크 케이블이 가득 찬 데이터 센터)에 대해 걱정할 필요가 없도록 서버 컴퓨터, 네트워크 및 스토리지를 관리하는 방식을 말합니다. 대신 조직은 이러한 자산을 주문형으로 프로비저닝하고 소비하는 서비스에 대한 비용을 지불할 수 있습니다.

클라우드 구성 - 조직에서 클라우드 제공업체를 이용하여 일부 소프트웨어를 실행하기 위해 설정한 일련의 클라우드 컴퓨팅 옵션입니다. 클라우드 구성의 예에는 허용되거나 차단되는 네트워크 연결 종류, 로그 파일이 기록되는 위치 및 보관 기간, 클라우드 구성을 변경할 권한이 있는 사용자 집합 등이 포함됩니다.

보정 관리 - 요구 사항의 일부 기준치와 다르지만 위험에 대해 비슷한 수준의 보호를 제공하기 위한 보안 관리입니다.

D

데이터베이스 - 임의의 데이터를 저장하고, 읽고, 업데이트하고, 삭제할 수 있는 소프트웨어입니다. 데이터베이스는 클라이언트와 서버에서 실행될 수 있습니다. Meta 플랫폼과 통합하는 조직은 일반적으로 그래프 API에서 가져오는 데이터를 서버 측에서 실행되는 데이터베이스에 저장합니다.

해독 - 암호화된 데이터를 원래 형식으로 다시 변환하는 프로세스입니다. 다시 말해서, 해독은 암호문을 평문으로 변경합니다.

E

암호화 - 어떤 데이터를 해독할 수 없는 사람은 이용할 수 없는 형식으로 데이터를 변환하는 프로세스입니다. 다시 말해서, 암호화는 평문을 암호문으로 변경합니다.

유휴 상태 암호화 - 영구 스토리지(예: 디스크 드라이브)에 기록될 때 암호화로 보호된 데이터입니다. 유휴 상태 암호화를 하면 스토리지 장치에서 원시 파일을 읽을 수 있는 사용자는 암호문을 볼 수 있지만 해독 키에도 접근할 수 있지 않은 한 암호를 해독할 수는 없으므로 무단 액세스로부터 추가적인 보호가 가능합니다.

전송 중 암호화 - 네트워크를 통해 전송될 때 암호화로 보호된 데이터입니다. 전송 중 암호화를 하면 네트워크 패킷을 읽을 수 있는 사용자는 암호문을 볼 수 있지만 해독 키에도 접근할 수 있지 않은 한 암호를 해독할 수는 없으므로 네트워크 경로를 통한 도청으로부터 보호가 가능합니다.

서비스 종료(EOL) 소프트웨어 - 조직에서 소프트웨어 제품에 대한 지원(예: 보안 취약점 해결을 위한 패치 생성)을 중단한 경우 해당 소프트웨어는 EOL로 간주됩니다. 이 소프트웨어는 더 이상 유지 관리되지 않으므로 EOL 소프트웨어를 실행하는 것은 매우 위험합니다.

G

Google Cloud Platform(GCP) - Google의 클라우드 컴퓨팅 서비스 제품군 그래프 API - 앱이 Meta 소셜 그래프에 읽고 쓰기를 하는 기본적인 방식입니다. 모든 Meta SDK 및 제품은 어떤 식으로든 그래프 API와 상호 작용합니다.

H

해시 함수 - 데이터를 입력으로 가져와서 원래 입력으로 되돌릴 수 없는 짧은 코드를 출력하는 암호화 함수입니다. 암호 기법에서 해시 함수는 비밀번호처럼 데이터를 보호하는 데 사용됩니다. 도난당할 수 있는 평문으로 사용자 비밀번호를 저장하는 대신 비밀번호를 해시 함수로 변환한 다음 저장합니다. 나중에 사용자가 올바른 비밀번호를 입력했는지 확인하기 위해 시스템에서 동일한 해시 함수를 사용하여 입력을 변환한 후 결과 해시를 저장된 값과 비교합니다. 출력 해시를 원래 입력으로 되돌릴 수 없으므로 일방향 함수라고도 합니다.

호스팅된 환경 - 조직이 자체 데이터 센터 또는 다른 고객과 공동 배치된 데이터 센터에서 실행 중인 일련의 원격 서버, 네트워크 및 스토리지 장치의 집합을 말합니다. 클라우드 컴퓨팅의 인기가 증가하고 있는 현대에는 이 배열이 상대적으로 흔하지 않습니다.

I

ID 공급자(IdP) - 디지털 ID 관리를 집중화하고 사용자를 인증하는 데 사용되는 클라우드 서비스입니다. IdP를 사용하는 조직에서는 일반적으로 사용자 인증을 위해 IdP를 사용하도록 클라우드 앱을 구성합니다. 그런 다음 조직은 IdP 내부에서 선택된 앱에 액세스 권한을 생성 및 부여하고, 사용자 계정을 비활성화하여 중앙에서 사용자를 관리할 수 있습니다. 따라서 각 클라우드 앱에서 이 작업을 반복할 필요가 없습니다.

ID 및 액세스 관리(IAM) - 계정을 관리하고 시스템에 대한 액세스 권한을 부여하는 데 사용되는 도구 및 프로세스의 카테고리를 말합니다.

IaaS(Infrastructure as a Service) - 고객이 물리적 자산에 대해 책임지지 않고(예: 서버, 네트워크 기기 및 스토리지 어레이로 가득 찬 데이터 센터 관리)컴퓨팅, 스토리지 및 네트워킹 서비스를 구성할 수 있도록 해주는 클라우드 컴퓨팅 접근 방식입니다. Paas와 비교하여 IaaS는 조직에 클라우드 자산의 구성에 대한 더 큰 통제력을 제공하지만 자산을 관리하기가 더 복잡합니다. 예를 들어 인기 있는 IaaS 제품은 다음과 같습니다. AWS EC2, Microsoft Azure IaaS, Google Compute Engine

L

라이브러리 - 다른 개발자의 앱 또는 시스템에서 특정 작업을 처리하는 데 사용되는, 일반적으로 외부 회사 또는 개발자의 기존 소프트웨어 빌딩 블록입니다. 주어진 기능에 대한 라이브러리가 이미 있으면 개발자가 시간을 낭비할 필요가 없으므로 라이브러리는 앱 개발을 간소화합니다. 하지만 라이브러리는 보안 취약점을 포함하거나 보안 취약점이 있는 추가 라이브러리를 포함할 수 있으므로, 라이브러리를 앱의 일부로 사용하는 개발자는 사용 중인 라이브러리가 어느 것인지 파악하고 시간이 지남에 따라 최신 상태로 업데이트해야 합니다.

M

모바일 클라이언트 또는 모바일 앱 - 개인이 모바일 앱 스토어(예: iOS App Store 또는 Google Play 스토어)로부터 휴대폰 또는 태블릿에 설치하는 앱입니다. 일반적으로 모바일 클라이언트는 인터넷을 통해 조직의 REST API와 통신하며 또한 다른 상대와도 소통할 수 있습니다(예: Android용 Facebook SDK를 통해 그래프 API와 소통).

다단계 인증(MFA) - 앱 또는 시스템에 액세스하기 위해 둘 이상의 단계를 수행해야 하는 인증 방식입니다. 비밀번호만으로 사용자를 인증하는 단일 요소 인증과 반대로, MFA는 일반적으로 비밀번호 외에도 이메일 또는 SMS를 통해 전송되는 코드, 인증 앱의 코드, 생체 인식 스캔, 보안 키 중 하나 이상을 요구합니다. MFA는 권한 없는 사용자가 계정에 강제로 진입(예: 알려진 이메일 주소와 흔한 비밀번호로 성공할 때까지 반복적으로 계정에 로그인 시도)하기 어렵게 만들어 계정 탈취로부터 보호합니다.

N

네이티브 소프트웨어 - 노트북 또는 모바일 기기에 다운로드하여 설치하는 앱을 네이티브 소프트웨어(예: iOS용 Facebook 앱)라고 합니다. 반대로 브라우저 내에서 실행되는 앱은 웹 앱이라고 합니다(예: Chrome 브라우저를 사용하여 Facebook 열기).

네트워크 도용 - 악의적인 사용자가 네트워크 자체의 잘못된 구성이나 취약점을 통해 조직의 내부 네트워크에 무단으로 액세스할 수 있는 경우를 네트워크 도용이라고 합니다. 네트워크 도용을 방어하려면 네트워크 스캔을 실행하여 인터넷 연결 네트워크에서 잘못된 구성 및 취약점을 파악합니다. 앱 도용도 참조하세요.

네트워크 스캔 - 소프트웨어를 사용하여 다음을 수행하는 위험 관리 프로세스입니다. (1) 네트워크에서 원격 커뮤니케이션에 응답하는 활성 서버를 식별한 다음 (2) 해당 서버에서 하나 이상의 보안 악용에 취약한 것으로 알려진 이전 버전의 소프트웨어를 실행 중인지 여부를 확인합니다. 예를 들어 조직에서 네트워크 스캔을 주기적으로 사용하여 네트워크 경계에 예기치 않게 열린 포트가 없도록 확인할 수 있습니다.

노드 패키지 관리자(NPM) - JavaScript 개발자가 사전 구축된 패키지를 개발자의 앱 또는 시스템에 포함하도록 허용하여 개발을 가속화하기 위해 사용하는 도구입니다. NPM은 앱에서 사용 중인 패키지 집합을 감사하거나 알려진 보안 취약점이 있는 패키지를 식별하는 기능을 포함합니다.

O

객체 스토리지 버킷 - 조직에서 스토리지 어레이와 같은 물리적 자산을 확장하거나 화재 또는 홍수와 같은 재해 시에 손실되지 않도록 파일을 백업하려고 신경 쓸 필요 없이, 매우 큰 파일을 비롯한 파일을 영구 스토리지에 간단하게 저장할 수 있도록 해주는 클라우드 내의 영구 스토리지의 한 유형입니다.

운영 체제 - 앱에서 컴퓨터의 프로세서, 메모리, 스토리지 및 네트워크 리소스를 실행하고 사용할 수 있도록 해주는 컴퓨터 또는 모바일 기기에서 실행 중인 소프트웨어입니다. 예를 들면 Microsoft Windows, Apple macOS 또는 iOS, Linux 등이 있습니다.

조직 멤버 - 조직 내에서 역할 및 책임이 있는 사람(예: 직원, 계약직, 임시 근로자, 인턴, 자원봉사자)입니다.

조직 기기 - 조직 멤버가 조직을 위해 업무를 수행하는 데 사용하는 컴퓨터 또는 모바일 기기입니다.

P

플랫폼 약관 6.a.i - 데이터 보안과 관련한 플랫폼 개발자의 의무를 설명하는 Meta 플랫폼 약관 (6)조 (a)항 (i)호를 말합니다.

패키지 - 라이브러리와 동의어

패치 - 보안 취약점을 해결하거나, 버그를 수정하거나, 새로운 기능을 추가하는 소프트웨어 업데이트입니다. 운영 체제, 컨테이너, 라이브러리, SDK를 비롯한 모든 종류의 소프트웨어는 패치됩니다.

침투 테스트 - 테스터가 코드 또는 구성에서 권한 없는 사용자에 의해 악용될 수 있는 취약점을 찾기 위해 시도하는 앱 또는 시스템에 대한 시뮬레이션 공격입니다. 침투 테스터는 사이버 범죄자와 유사한 도구를 사용하여 정찰을 수행하고, 잠재적 약점을 살피고, 무단 액세스를 위해 이용될 수 있는 취약점을 테스트합니다. 침투 테스트를 마친 후 테스터는 결과를 각각의 심각도와 함께 설명하는 보고서를 만듭니다. 그리고 소프트웨어를 유지 관리하는 조직은 취약점을 해결하기 위한 수정 사항 진행을 담당합니다.

평문 - 암호화되지 않은 데이터의 동의어인 평문은 암호화로 보호되지 않는 데이터에 붙여진 이름입니다. PaaS(Platform as a Service) - 고객이 클라우드 제공업체에 의해 관리되는 플랫폼에 앱을 배포하는 클라우드 컴퓨팅 접근 방식입니다. IaaS에 비해 PaaS는 물리적 자산(즉, 서버, 스토리지 기기, 네트워크 기기)뿐 아니라 고객의 앱이 실행되는 운영 체제와 앱 컨테이너도 클라우드 호스트에서 관리되므로 고객이 관리하기가 더욱 간단해집니다. 예를 들어 인기 있는 PaaS 제품은 다음과 같습니다. AWS Elastic Beanstalk, Google App Engine, Force.com

포트 - 클라이언트가 인터넷을 통해 서버에 연결하는 경우 목적지 주소는 다음 두 부분으로 구성됩니다. (1) 서버를 위한 인터넷 프로토콜(IP) 주소, (2) 해당 서버에서 특정 앱이 응답하는 포트 번호. 일반 프로토콜에서는 예약된 포트를 사용하지만(예: HTTPS에서는 443 사용) 개발자는 원하는 경우 네트워크 커뮤니케이션에 직접 지정한 포트를 사용할 수 있습니다.

R

REST API - 클라이언트 및 서버에서 HTTP 프로토콜을 사용하여 통신하는 데 널리 채택되는 웹 액세스 가능 서비스의 구축 방식입니다. Meta 플랫폼에서 개발자는 모바일 앱이 플랫폼 데이터를 주고받는 api.example.com과 같은 하위 도메인에 REST API를 호스팅할 수 있습니다.

S

보안 셸(SSH) - 관리자가 서버에 원격으로 로그인하여 해당 서버에서 프로그램을 실행할 수 있도록 해주는 커뮤니케이션 방식입니다. 텔넷과 같은 예전 프로토콜과 달리 클라이언트와 서버 사이의 커뮤니케이션이 도청으로부터 보호되므로 보안이라고 부릅니다. 보안 소켓 셸이라고도 합니다.

Secure Sockets Layer(SSL) - 더 이상 사용되지 않고 보안도 되지 않는 버전의 전송 중 암호화입니다. 최신 보안 버전을 전송 계층 보안(TLS)이라고 합니다.

서버 - 네트워크를 통해 원격으로 서비스를 제공하는 컴퓨터입니다. 브라우저와 모바일 앱은 인터넷을 통해 서버에 연결됩니다.

서버리스 컴퓨팅 - 클라우드 호스트가 물리적 인프라, 서버 운영 체제 및 컨테이너를 관리하는 클라우드 컴퓨팅 방식입니다. 개발자는 클라우드 구성과 함께 직접 지정한 코드 및 연결된 라이브러리만 담당합니다.

서버 측 - 네트워크 연결의 반대 측에 있는(즉, 서버에 있는) 데이터 또는 컴퓨터를 서버 측이라고 합니다. 반대로 노트북, 모바일 기기와 같은 로컬 기기에 있는 데이터 또는 컴퓨터를 클라이언트 측이라고 합니다.

SSO(Single Sign On) - 앱에서 중앙 집중식 사용자 디렉터리(즉, IdP)를 사용하여 사용자를 인증하는 배열입니다. 조직에 대한 사용자 계정 및 앱 액세스 관리를 집중화하는 외에도 사용자에게 앱별로 다른 자격 증명(예: 사용자 이름과 비밀번호)을 유지하도록 요구하는 대신 단일 자격 증명을 사용하게 할 수 있어 좋습니다.

소프트웨어 개발 키트(SDK) - 개발자가 필요에 의해 개발 프로세스를 간소화하는 데 사용할 수 있는 코드의 빌딩 블록입니다. 예를 들어 Meta는 iOS 및 Android 개발자용 그래프 API 작업을 간소화하는 SDK를 만들고 유지 관리합니다. 라이브러리와 마찬가지로 자신의 앱에서 SDK를 사용하는 개발자는 시간이 지남에 따라 최신 상태로 업그레이드해야 합니다.

SaaS(Software as a Service) - 고객이 인터넷을 통해 클라우드 기반 앱을 사용할 수 있도록 해줍니다. PaaS 또는 IaaS와 달리 SaaS 앱 고객은 직접 지정한 코드를 배포하지 않으며 SaaS 앱을 구성, 업그레이드 또는 패치할 책임이 없습니다. 이러한 모든 책임은 전적으로 SaaS 소프트웨어 벤더에게 있습니다. 예를 들어 인기 있는 SaaS 제품은 다음과 같습니다. Dopbox, MailChip, Salesforce, Slack

정적 분석 - 정적 앱 보안 테스트 참조

정적 앱 보안 테스트(SAST) - 소스 코드에 대해 특수 도구를 실행하여 소프트웨어의 취약점을 찾는 방식입니다. SAST 도구는 OWASP Top 10 프로젝트에 나열된 것과 같은 잠재적 취약점을 파악합니다. 그런 다음 결과를 검토하고, 정탐지와 오탐지를 구별하고, 소프트웨어의 취약점을 해결할 책임은 개발자에게 있습니다. SAST는 취약점이 프로덕션에 배포되기 전에 개발자가 찾을 수 있도록 해주므로 유용하지만, 침투 테스트와 달리 SAST 도구는 앱의 프로덕션 구성 관련 취약점은 찾을 수 없습니다.

T

투명한 데이터 암호화 - 데이터베이스 스토리지(즉, 데이터베이스 콘텐츠 자체 및 그 로그 파일)에 일반적으로 적용되는 일종의 유휴 상태 암호화입니다. 이 배열에서 데이터베이스 소프트웨어는 암호화 키를 관리하고 암호화 작업(쓰기)과 해독 작업(읽기)을 투명하게 처리합니다.

전송 계층 보안(TLS) - 암호화를 사용하여 네트워크를 통해 전송되는 데이터를 네트워크 경로를 타고 오는 도청자로부터 보호하는 전송 중 암호화 방식입니다. TLS는 더 이상 사용되지 않는 예전 기술인 SSL의 최신 보안 버전입니다.

2단계 인증(2Fac) - 다단계 인증과 동의어입니다. 볼트 - 암호화 키, 액세스 토큰 및 기타 자격 증명과 같은 민감한 데이터를 위한 보안 관리 시스템입니다. 볼트는 그 안에 담고 있는 비밀 정보에 액세스할 수 있는 사람들에 대해 엄격한 제어를 가능하게 해주며, 추가 서비스(예: 감사 로그 보관)를 제공합니다.

V

가상 머신(VM) - 앱 컨테이너와 매우 흡사하지만, VM은 하이퍼바이저라는 호스트에서 실행되는 반면 앱 컨테이너는 컨테이너 엔진에서 실행됩니다. 주요 차이점은 VM 이미지에는 운영 체제가 포함되어 있고, 앱 컨테이너에는 그렇지 않다는 것입니다. VM과 앱 컨테이너는 모두 앱과 종속성(예: 라이브러리)을 포함합니다.

VPC(Virtual Private Cloud) - AWS에서 클라우드 이전 시대의 데이터 센터 내 기존 네트워크와 흡사한 클라우드 리소스 집합을 나타내는 데 사용되는 용어입니다.

취약점 - 시스템 또는 앱에서 악용될 수 있는(예: 읽을 권한이 없는 데이터 읽기) 결함입니다.

취약점 공개 프로그램(VDP) - 악의적인 사용자가 악용하기 전에 취약점을 찾아서 해결할 수 있도록 조직에서 연구원(윤리적 해커라고도 함)에게 보안 취약점 보고서를 요청하는 접근 방식입니다. 효과적인 VDP에는 취약점을 적극적으로 조사하는 연구원, 조직 내에서 들어오는 공개 사항을 검토 및 분류하는 분석가, 취약점에 대한 수정 사항을 만들어서 배포할 수 있는 사이버 보안 관련 지식이 풍부한 엔지니어의 집단이 필요합니다.

취약점 스캔 - 소프트웨어를 사용하여 서버, 네트워크 및 앱에서 취약점을 찾는 접근 방식입니다. 침투 테스트에 비해 취약점 스캔은 실행 비용이 더 저렴하여 반복적으로(예: 월별 또는 분기별) 실행할 수 있지만, 숙련된 침투 테스터는 엄격하게 자동화된 접근 방식으로 대체하기 어려운 직감과 분석 기술을 활용하므로, 취약점 스캔에서 놓친 취약점을 침투 테스트에서 찾아내는 것이 일반적입니다. 네트워크 스캔도 참조하세요.

W

웹 앱 - 웹 앱은 브라우저 내부에서 실행되고 HTML 문서, JavaScript 코드, 비디오 및 기타 미디어, 스타일 지정용 CSS와 같은 리소스로 구성되는 프로그램입니다. 사용자가 앱 스토어로부터 휴대폰에 설치하는 모바일 앱과 반대로, 웹 앱은 설치 단계를 수행할 필요 없이 브라우저를 사용하여 원격 서버(예: www.facebook.com)에서 간단하게 가져올 수 있습니다.