보안 도메인: 데이터 처리 보안 및 개인 정보

아티클
03/05/2024

이 보안 도메인은 Microsoft 365에서 사용된 모든 데이터가 전송 중 및 미사용 시 적절하게 보호되도록 설계되었습니다. 이 도메인은 또한 소비자(데이터 주체) 개인 정보 보호 문제가 GDPR(일반 데이터 보호 규정) 및 HIPAA(1996년 건강 보험 이식성 및 책임법)에 따라 ISV에 의해 충족되도록 합니다.

전송 중인 데이터

Microsoft 365에서 개발한 앱/추가 기능의 연결 요구 사항은 공용 네트워크, 특히 인터넷을 통한 통신이 필요합니다. 따라서 전송 중인 데이터는 적절하게 보호되어야 합니다. 이 섹션에서는 인터넷을 통한 데이터 통신 보호에 대해 설명합니다.

컨트롤 번호 1

다음 중 모두에 대한 증거를 제공하세요.

TLS 구성이 TLS1.2 이상인지 확인합니다.
신뢰할 수 있는 키 및 인증서의 인벤토리는 유지 관리되고 유지 관리됩니다.

의도: TLS

이 하위 지점의 의도는 organization 사용하는 Microsoft 365 데이터가 안전하게 전송되도록 하기 위한 것입니다. TLS 프로필 구성은 트래픽이 중간 수준의 공격에 대해 안전한지 확인하는 데 도움이 되는 TLS 특정 요구 사항을 정의하는 데 사용됩니다.

지침: TLS

이를 입증하는 가장 쉬운 방법은 비표준 포트에서 실행되는 모든 웹 수신기를 포함하여 모든 웹 수신기에 대해 Qualys SSL 서버 테스트 도구를 실행하는 것입니다.

URL이 웹 사이트에 추가되지 않도록 하는 "보드에 결과 표시 안 함" 옵션을 선택해야 합니다.

TLS 프로필 구성 요구 사항은 개별 검사의 증거를 제공하여 확인할 수 있습니다. TLS 압축을 사용하지 않도록 설정하는 것과 같은 특정 설정의 증거를 제공하려면 구성 설정, 스크립트 및 소프트웨어 도구를 활용할 수 있습니다.

예시 증거: TLS

다음 스크린샷은 webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net 대한 Qualys의 SSL 검사 결과를 보여 줍니다.

Qualys 보고서에 의한 SSL 검사

프로토콜 섹션에서는 TLS1.2가 지원/활성화된 유일한 프로토콜임을 보여 줍니다.

Qualys 보고서에 의한 SSL 검사

참고: 인증 분석가는 검사의 전체 출력을 검토하여 TLS 프로필 구성 요구 사항의 모든 요구 사항이 충족되는지 확인합니다. scope 백 엔드 환경에 공개적으로 노출되는 모든 엔드포인트(IP 주소 및 URL)에 대한 검사가 제공될 것으로 기대됩니다. 어떤 증거가 제공되었는지에 따라 분석가는 자체 Qualys 검사를 실행할 수 있습니다.

예시 증거: TLS

다음 스크린샷은 Azure App Service의 TLS에 대한 구성 설정과 PowerShell을 통한 TLS 열거형을 보여줍니다.

Azure 웹앱 구성 설정

의도: 키 및 인증서

이 하위 지점의 의도는 신뢰할 수 있는 키 및 인증서의 포괄적인 인벤토리가 유지 관리되도록 하기 위한 것이며, 여기에는 이러한 암호화 요소에 의존하는 다양한 시스템, 서비스 및 애플리케이션을 식별하는 작업이 포함됩니다.

지침: 키 및 인증서

증거는 신뢰할 수 있는 키 및 인증서의 인벤토리가 존재하고 유지 관리됨을 입증해야 합니다. 또한 실제 키 및 인증서를 저장하는 데 사용되는 도구의 적용 가능한 증거는 Azure Key Vault, HashiCorp 자격 증명 모음 비밀, Confluence Cloud 등과 같이 제공할 수 있습니다.

예제 증거: 키 및 인증서

다음 스크린샷은 Confluence Cloud에서 키 및 인증서 인벤토리가 유지 관리됨을 보여줍니다.

Confluence 인증서 인벤토리.

다음 스크린샷은 신뢰할 수 있는 키 및 인증서의 승인된 목록을 보여 줍니다. 여기에는 인증서, 키, 암호 및 설치된 시스템과 같은 세부 정보가 포함됩니다.

Confluence 인증서 인벤토리.

다음 스크린샷은 HashiCorp Vault의 스크린샷입니다. 인벤토리 목록에 설명되고 기록된 인증서는 이 온라인 자격 증명 모음에 저장됩니다. HashiCorp Vault는 비밀 관리, 서비스로서의 암호화 및 권한 있는 액세스 관리를 위한 오픈 소스 도구입니다.

Hashicorp 자격 증명 모음 dashboard.

다음 스크린샷은 실제 인증서 및 온라인 자격 증명 모음 내에 저장된 키의 추출입니다.

Hashicorp 자격 증명 모음 dashboard.

참고: 키의 스토리지 위치에 적절한 액세스 제어가 있어야 합니다. 프라이빗 키가 손상된 경우 누군가가 합법적인 인증서로 서버를 스푸핑할 수 있습니다.

예제 증거: 키 및 인증서

다음 스크린샷과 같이 인벤토리 기능을 제공하는 Microsoft 365 Defender를 사용하여 신뢰할 수 있는 키 및 인증서의 인벤토리를 유지할 수도 있습니다.

Microsoft Defender 인벤토리 페이지.

다음 스크린샷은 인증서의 세부 정보를 보여줍니다.

Microsoft Defender 인벤토리 페이지.

참고: 이러한 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자 및 증거 검토를 위한 시간 및 날짜 스탬프가 필요합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.

컨트롤 번호 2

다음의 모든 사항에 대한 증거를 제공하세요.

범죄 방지를 위해 웹 요청을 처리하는 모든 퍼블릭 서비스에 대해 TLS 압축을 사용하지 않도록 설정됨 표시(압축 비율 정보 누수가 쉬워지게 함).
TLS HSTS가 사용하도록 설정되고 모든 사이트에서 180일로 구성되었는지 확인합니다.

의도: TLS

범죄(압축 비율 정보 누수 쉽게 만들기(CVE-2012-4929)) 공격은 SSL(Secure Sockets Layer)/TLS(전송 계층 보안) 프로토콜의 압축에 취약성이 있습니다. 이러한 이유로 업계 권장 사항은 SSL 압축을 사용하지 않도록 설정하는 것입니다.
HSTS(HTTP Strict Transport Security)는 "Strict-Transport-Security"라는 HTTPS 응답 헤더 필드를 통해 TLS 연결을 강제하여 중간자 공격으로부터 웹 사이트를 보호하도록 설계된 보안 메커니즘입니다.

지침: TLS

Qualys SSL Labs 도구를 통해 확인할 수 있습니다. 예시 증거: TLS

다음 스크린샷은 SSL/TLS 압축을 사용할 수 없음을 보여 줍니다.

Qualys SSL 랩 도구 보고서입니다.

다음 스크린샷은 HSTS가 사용하도록 설정되어 있음을 보여 줍니다.

Qualys SSL 랩 도구 보고서입니다.

참고: 인증 분석가는 전체 출력을 검토하여 TLS 프로필 구성 요구 사항의 모든 요구 사항이 충족되는지 확인합니다(전체 검사 출력의 스크린샷을 제공하세요). 어떤 증거가 제공되었는지에 따라 분석가는 자체 Qualys 검사를 실행할 수 있습니다.

HSTS를 사용하는 검사 데 사용할 수 있는 다른 도구는 'HTTP 헤더 스파이'입니다.

다음 예제와 같이 securityheaders.com. 추가 증거

보안 헤더의 구성 설정, 특히 HSTS와 같은 스크린샷을 제공하여 퍼블릭 공간의 보안 상태를 더 자세히 보여 줄 수 있습니다.

다음 스크린샷은 Azure Front Door 구성 및 헤더를 다시 쓰기 위해 구현된 규칙 집합을 보여 줍니다.

Azure Front Door 구성 설정

다음 스크린샷은 HSTS뿐만 아니라 모든 보안 헤더가 구현되는 보안 헤더 검색을 보여 줍니다.

보안 보고서 요약

참고: Qualys SSL 스캐너 또는 보안 헤더를 사용하는 경우 검토를 위해 전체 보고서가 제공될 것으로 예상합니다.

미사용 데이터

Microsoft 365 플랫폼에서 사용된 데이터가 ISV에 의해 저장되는 경우 데이터를 적절하게 보호해야 합니다. 이 섹션에서는 데이터베이스 및 파일 저장소 내에 저장된 데이터의 보호 요구 사항에 대해 설명합니다.

컨트롤 번호 3

AES, Blowfish, TDES 및 128비트 및 256비트 암호화 키 크기와 같은 암호화 알고리즘을 사용하여 미사용 데이터가 암호화 프로필 요구 사항에 따라 암호화된다는 입증 가능한 증거를 제공합니다.

의도:

일부 이전 암호화 알고리즘에는 일부 암호화 약점이 포함되어 있어 위협 행위자가 키에 대한 지식 없이 데이터를 해독할 가능성이 높아집니다. 이러한 이유로 이 제어의 목적은 업계에 허용되는 암호화 알고리즘만 저장된 M365 데이터를 보호하는 데 사용되도록 하기 위한 것입니다.

지침:

데이터베이스 및 기타 스토리지 위치 내에서 M365 데이터를 보호하기 위해 사용 중인 암호화를 보여 주는 스크린샷을 통해 증거를 제공할 수 있습니다. 증거는 암호화 구성이 Microsoft 365 인증의 암호화 프로필 구성 요구 사항 과 일치한다는 것을 입증해야 합니다.

예시 증거:

다음 스크린샷은 Contoso 데이터베이스에서 TDE(투명한 데이터 암호화)가 사용하도록 설정되어 있음을 보여줍니다. 두 번째 스크린샷은 AES 256 암호화가 Azure TDE에 사용됨을 보여 주는 SQL Database, SQL Managed Instance 및 Azure Synapse Analytics에 대한 투명한 데이터 암호화 Microsoft 설명서 페이지를 보여줍니다.

SQL 투명한 데이터 암호화 설정

참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.

Microsoft learn Azure SQL 문서.

예시 증거:

다음 스크린샷은 Blob 및 파일에 대한 암호화로 구성된 Azure Storage를 보여 줍니다. 다음 스크린샷은 미사용 데이터에 대한 Microsoft 설명서 페이지 Azure Storage 암호화를 보여 줍니다. Azure Storage는 암호화에 AES-256을 사용합니다.

Azure Store 계정 암호화 설정

Microsoft는 Azure Storage 암호화 문서에 대해 알아봅니다.

데이터 보존, 백업 및 삭제

ISV가 Microsoft 365 데이터를 사용하고 저장하는 경우 위협 행위자가 ISV 환경을 손상시킬 경우 데이터 손상 위험이 있습니다. 이러한 위험을 최소화하기 위해 조직은 서비스를 제공하는 데 필요한 데이터만 유지해야 하며 나중에 "사용할 수 있는" 데이터는 유지해야 합니다. 또한 데이터가 캡처된 서비스를 제공하는 데 필요한 경우에만 데이터를 유지해야 합니다. 데이터 보존을 정의하고 사용자와 통신해야 합니다. 데이터가 정의된 보존 기간을 초과하면 데이터를 다시 구성하거나 복구할 수 없도록 안전하게 삭제해야 합니다.

컨트롤 번호 4

승인된 데이터 보존 기간이 공식적으로 설정되고 문서화되었다는 증거를 제공하세요.

의도:

문서화된 보존 정책은 EU GDPR(일반 데이터 보호 규정) 및 데이터 보호법(영국 DPA 2018)과 같은 데이터 개인 정보 보호 법률과 같은 일부 법적 의무를 충족할 뿐만 아니라 조직의 위험을 제한하는 데 중요합니다. 조직 데이터 요구 사항 및 비즈니스에서 기능을 수행하는 데 필요한 데이터 기간을 이해하면 유용성이 만료되면 데이터가 올바르게 삭제되도록 할 수 있습니다. 조직은 저장된 데이터의 양을 줄임으로써 데이터 손상이 발생할 경우 노출되는 데이터의 양을 줄입니다. 이렇게 하면 전반적인 영향이 제한됩니다.

경우에 대비하여 데이터를 저장하는 것이 좋기 때문에 조직에서 데이터를 저장하는 경우가 많습니다. 그러나 organization 서비스 또는 비즈니스 기능을 수행하기 위해 데이터가 필요하지 않은 경우 organization 위험이 불필요하게 증가하므로 데이터를 저장해서는 안 됩니다.

이 컨트롤의 목적은 organization 모든 관련 데이터 형식에 대해 승인된 데이터 보존 기간을 공식적으로 설정하고 문서화했는지 확인하는 것입니다. 여기에는 다양한 형식의 데이터가 저장되는 기간을 지정할 뿐만 아니라 데이터 삭제 또는 보관 후 만료 절차를 간략하게 설명합니다.

지침:

비즈니스가 비즈니스 기능을 수행할 수 있도록 데이터(모든 데이터 형식을 포함해야 하는 기간)를 명확하게 자세히 설명한 전체 데이터 보존 정책을 제공합니다.

예시 증거:

다음 스크린샷은 Contoso의 데이터 보존 정책을 보여 줍니다.

데이터 보존 정책 문서입니다.

참고: 이러한 스크린샷은 정책/프로세스 문서의 스냅샷 보여 줍니다. ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

컨트롤 번호 5

컨트롤 4에서 설명한 대로 정의된 보존 기간 동안만 데이터가 보존됨을 보여 줍니다.

의도:

이 컨트롤의 의도는 정의된 데이터 보존 기간이 충족되고 있는지 유효성을 검사하기 위한 것입니다. 이미 설명한 대로 조직은 이를 충족해야 할 법적 의무가 있을 수 있지만, 필요한 데이터를 유지하고 필요한 한 데이터 위반이 발생할 경우 organization 위험을 줄이는 데 도움이 됩니다. 이렇게 하면 데이터가 지나치게 긴 기간 동안 보존되거나 조기에 삭제되지 않으며, 둘 다 법적, 운영 또는 보안과 관련된 다양한 성격의 위험을 초래할 수 있습니다.

지침:

저장된 데이터(예: 데이터베이스, 파일 공유, 보관 등)가 정의된 데이터 보존 정책을 초과하지 않음을 보여 주는 스크린샷 증거(또는 스크린 공유를 통해)를 제공합니다. 예제는 다음의 스크린샷일 수 있습니다.

날짜 필드가 있는 데이터베이스 레코드, 가장 오래된 레코드 순서로 검색 및/또는
보존 기간 내에 있는 타임스탬프를 보여 주는 파일 스토리지 위치 참고: 개인/중요한 고객 데이터는 스크린샷 내에서 수정해야 합니다.

예시 증거:

다음 증거는 데이터베이스 내에서 가장 오래된 레코드를 표시하기 위해 'DATE_TRANSACTION' 필드에 오름차순으로 정렬된 데이터베이스 테이블의 내용을 보여 주는 SQL 쿼리를 보여 줍니다. 데이터가 정의된 보존 기간을 초과하지 않는 2개월 미만임을 보여 줍니다.

SQL 쿼리 편집기.

참고: 이 데이터베이스는 테스트 데이터베이스이므로 그 안에 기록 데이터가 많지 않습니다.

컨트롤 번호 6

보존 기간 후에 데이터를 안전하게 삭제하기 위한 프로세스가 마련되어 있음을 보여 줍니다.

의도:

이 컨트롤의 의도는 보존 기간을 초과하는 데이터를 삭제하는 데 사용되는 메커니즘이 안전하게 수행되도록 하는 것입니다. 삭제된 데이터는 때때로 복구될 수 있습니다. 따라서 삭제 프로세스는 삭제된 후 데이터를 복구할 수 없도록 충분히 강력해야 합니다.

지침:

삭제 프로세스가 프로그래밍 방식으로 수행되는 경우 이를 수행하는 데 사용되는 스크립트의 스크린샷을 제공합니다. 일정에 따라 실행되는 경우 일정을 보여 주는 스크린샷을 제공합니다. 예를 들어 파일 공유 내에서 파일을 삭제하는 스크립트는 CRON 작업으로 구성될 수 있으며, 실행 중인 일정 및 스크립트를 보여 주는 CRON 작업 스크린샷 및 는 사용된 명령을 보여 주는 스크립트를 제공합니다.

예시 증거:

이 스크립트는 날짜에 따라 보존된 모든 데이터 레코드를 삭제하는 데 사용할 수 있는 간단한 스크립트입니다. WHERE DateAdd는 -30일이므로 선택한 데이터 보존 날짜보다 30일 이전의 보존된 모든 레코드가 제거됩니다. 스크립트가 필요합니다. 실행 중인 작업의 증거 및 결과입니다.

스크립트 줄입니다.

예시 증거:

다음 스크린샷은 Contoso 데이터 보존 정책(컨트롤 4)에서 가져온 것입니다. 데이터 삭제에 사용되는 절차를 보여 줍니다.

데이터 보존 정책 문서입니다.

참고: 이 스크린샷은 정책/프로세스 문서의 스냅샷 보여줍니다. ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

예시 증거:

이 예제에서는 데이터 레코드 보존 정책이 만료된 후 30일 후에 만든 종료 날짜가 있는 레코드를 안전하게 삭제하기 위해 Azure에서 Runbook을 만들고 해당 일정을 만들었습니다. 이 작업은 매월 마지막 날에 실행되도록 설정됩니다.

Azure 데이터 보존 설정.

다음 스크린샷은 Runbook이 레코드를 찾기 위해 편집되었으며 스크립트와 같이 표시되지 않는 삭제 명령이 있음을 보여 줍니다.

Azure 데이터 보존 설정.

참고: 전체 URL 및 사용자 이름은 이러한 스크린샷에 대한 보기에 있어야 하며, 삭제 전 레코드 수의 스크린샷과 삭제된 레코드 수 이후의 스크린샷을 표시하려면 ISV가 필요합니다.

Azure 데이터 보존 설정.

이러한 스크린샷은 이 방법을 접근할 수 있는 다양한 방법의 예입니다.

Azure 데이터 보존 설정.

컨트롤 번호 7

다음을 보여주는 증거를 제공하세요.

자동화된 백업 시스템이 설치되어 있으며 예약된 시간에 백업을 수행하도록 구성됩니다.
백업 정보는 백업 예약 절차에 따라 테스트되고 주기적으로 복원되어 데이터의 안정성과 무결성을 확인합니다.
백업/시스템 스냅샷이 무단 액세스에 대해 보호되고 백업 데이터의 기밀성, 무결성 및 가용성을 보장하기 위해 적절한 액세스 제어 및 보호 메커니즘(즉, 변경할 수 없는 백업)이 구현됩니다.

의도:

이 컨트롤의 목적은 organization 미리 결정된 시간에 백업을 실행하도록 구성된 자동화된 백업 시스템이 있는지 확인하는 것입니다.

지침:

백업이 예약된 기간/시간 간격으로 수행되고 있음을 보여 주는 백업 솔루션의 구성 설정 스크린샷을 제공하세요. 솔루션에서 백업 예약을 자동으로 수행하는 경우 공급업체 설명서를 제공하여 지원될 수 있습니다.

예시 증거:

다음 스크린샷은 관리되는 instance Azure Database for MySQL 적용됩니다. 첫 번째 자동화된 백업이 완료되었음을 나타냅니다.

Azure 백업 및 복원 설정.

다음 스크린샷은 추가 전체 백업이 수행되었음을 보여 주는 기간이 경과한 후에 수행됩니다. 유연한 서버의 백업은 서버를 만든 직후에 첫 번째 스냅샷 백업이 예약되고 스냅샷 백업이 매일 한 번 수행되는 스냅샷 기반입니다.

Azure 백업 및 복원 설정.

다음 스크린샷은 백업 빈도 및 자동화된 백업 기능을 간략하게 설명하는 온라인 설명서의 스냅샷 보여 줍니다.

자동화된 백업 문서를 learn.microsoft.com.

의도:

이 컨트롤의 목적은 백업 정보가 일정에 따라 생성될 뿐만 아니라 신뢰할 수 있고 시간이 지남에 따라 무결성을 유지한다는 것을 입증하는 것입니다. 이 목표를 달성하기 위해 백업 데이터에 대해 주기적인 테스트가 수행됩니다.

지침:

이 제어를 충족하는 증거는 백업 데이터를 테스트하기 위한 organization 프로세스 및 절차에 따라 달라집니다. 기록 테스트 완료 기록과 함께 성공적으로 테스트되는 백업을 보여 주는 증거를 제공할 수 있습니다.

예시 증거:

다음 스크린샷은 백업 일정 및 복원 프로시저가 존재하고 유지 관리되며 Confluence 플랫폼에서 수행되는 백업 빈도를 포함하여 모든 적용 가능한 시스템에 대해 백업 구성이 정의되어 있음을 보여 줍니다.

Confluence 백업 및 복원 설정.

다음 스크린샷은 적용 가능한 각 시스템에 대한 백업 테스트 기록의 페이지를 보여줍니다. 테이블의 오른쪽에 있는 JIRA 티켓이 각 테스트에 대해 참조되는지 확인합니다.

Confluence 백업 및 복원 설정.

다음 네 개의 스크린샷은 스냅샷 Azure Database for MySQL 복원하는 엔드 투 엔드 프로세스를 보여 줍니다. '빠른 복원' 옵션을 사용하여 SQL 데이터베이스의 복원 프로세스를 시작할 수 있습니다.

Azure 백업 및 복원 설정.

다음 스크린샷은 복원을 사용자 지정할 수 있는 구성 페이지를 보여줍니다.

Azure 백업 및 복원 설정.

데이터베이스를 복원할 대상 위치, 네트워킹 및 스냅샷 선택하면 배포를 시작할 수 있습니다. 데이터베이스 instance 이제 '테스트'라고 합니다.

Azure 배포 개요.

총 5분 후에 SQL 데이터베이스가 성공적으로 복원되고 백업 스냅샷 완전히 복원되었습니다.

Azure 배포 개요.

테스트가 완료되면 프로세스에 따라 백업 테스트 및 수행된 복원의 세부 정보를 기록하기 위해 JIRA 티켓이 만들어졌습니다. 이렇게 하면 기록 데이터를 규정 준수 목적으로 사용할 수 있을 뿐만 아니라 인시던트 또는 재해의 발생 여부를 검토하기 위해 전체 레코드가 존재하여 organization 근본 원인 분석을 수행할 수 있습니다.

Jira 백업 티켓.

의도:

이전 컨트롤에서 앞서 백업 데이터를 담당하는 개별 사용자에 대한 액세스를 제한하기 위해 액세스 제어를 구현해야 합니다. 액세스를 제한하여 무단 변경이 수행될 위험을 제한하여 안전하지 않은 변경을 도입합니다. 백업을 보호하기 위해 최소 권한 있는 접근 방식을 취해야 합니다.

데이터를 제대로 보호하려면 조직에서 환경/시스템이 사용하는 데이터와 데이터가 저장되는 위치를 알고 있어야 합니다. 일단 이것이 완전히 이해되고 문서화되면.

그러면 조직은 적절한 데이터 보호를 구현할 수 있을 뿐만 아니라 데이터가 있는 위치를 통합하여 보호를 보다 효과적으로 구현할 수 있습니다. 또한 데이터를 가능한 한 적은 수의 위치로 통합하는 경우 적절한 RBAC(역할 기반 액세스 제어)를 구현하여 필요한 직원 수만큼 적은 수의 직원으로 액세스를 제한하는 것이 훨씬 쉽습니다.

지침:

승인된 액세스 목록의 지원 설명서를 사용하여 백업 및 백업 솔루션에 대한 액세스 권한을 보여주는 데 사용되는 시스템/기술에서 증거를 제공해야 합니다.

예시 증거:

다음 스크린샷에서는 액세스 제어가 데이터베이스 instance 구현되어 작업 역할에 따라 권한이 있는 개인에 대해서만 액세스를 제한한다는 것을 확인할 수 있습니다.

Azure 액세스 제어 dashboard.

예시 증거:

Azure SQL Database 및 Azure SQL Managed Instances 자동화된 백업은 Azure에서 관리되며 무결성은 Azure 플랫폼의 책임입니다. 사용자는 액세스할 수 없으며 랜섬웨어 공격 가능성 없이 미사용 시 암호화됩니다. 또한 보호를 위해 다른 지역으로 복제됩니다.

정책 문서를 learn.microsoft.com Azure SQL.

데이터 액세스 관리

데이터가 악의적이거나 실수로 손상될 가능성을 줄이기 위해 필요한 경우 데이터 액세스를 제한해야 합니다. 데이터 및 암호화 키에 대한 액세스는 업무 역할을 수행하기 위해 합법적인 비즈니스 액세스가 필요한 사용자로 제한되어야 합니다. 액세스를 요청하는 잘 문서화되고 잘 설정된 프로세스를 구현해야 합니다. 데이터 및 암호화 키에 대한 액세스는 최소 권한 원칙을 따라야 합니다.

컨트롤 번호 8

데이터 및/또는 암호화 키에 액세스할 수 있는 개인 목록을 보여 주는 증거를 제공합니다.

는 각 개인에 대한 비즈니스 근거를 포함하여 유지 관리됩니다.
는 작업 기능에 필요한 액세스 권한에 따라 공식적으로 승인되었습니다.
는 승인에 설명된 권한으로 구성됩니다.

의도:

조직은 데이터 및 암호화 키에 대한 액세스를 가능한 한 적은 직원으로 제한해야 합니다. 이 제어의 목적은 데이터 및/또는 암호화 키에 대한 직원 액세스가 해당 액세스에 대한 명확한 비즈니스 요구 사항이 있는 직원으로 제한되도록 하는 것입니다.

지침:

데이터 및/또는 암호화 키에 대한 액세스 권한이 있는 모든 직원을 문서화하는 내부 시스템의 설명서 또는 스크린샷과 이러한 개인에게 액세스 권한이 있는 이유에 대한 비즈니스 근거를 제공해야 합니다. 이 목록은 인증 분석가가 다음 컨트롤에 대한 사용자를 샘플링하는 데 사용됩니다.

예시 증거:

다음 문서에서는 데이터에 액세스할 수 있는 사용자 목록과 비즈니스 근거를 보여줍니다.

승인된 사용자 액세스 문서입니다.

참고: 이 스크린샷은 ISV가 실제 지원 정책/절차 설명서를 공유하기를 기대하는 정책/프로세스 문서를 보여줍니다.

의도:

데이터 및/또는 암호화 키에 대한 액세스 권한을 부여하는 프로세스에는 승인이 포함되어야 하며, 해당 작업 기능에는 개인의 액세스 권한이 필요합니다. 이렇게 하면 진정한 액세스 이유가 없는 직원이 불필요한 액세스 권한을 얻지 못하도록 합니다.

지침:

일반적으로 이전 컨트롤에 제공된 증거는 이 컨트롤을 지원하는 데 도움이 될 수 있습니다. 제공된 설명서에 대한 공식적인 승인이 없는 경우 증거는 Azure DevOps 또는 Jira와 같은 도구 내에서 액세스에 대한 변경 요청을 제기하고 승인하는 것으로 구성될 수 있습니다.

예시 증거:

이 이미지 집합은 컨트롤(i)이 중요한 데이터 및/또는 암호화 키에 대한 액세스 권한을 부여하거나 거부할 수 있도록 만들어지고 승인된 Jira 티켓을 보여줍니다. 이 이미지는 Jira에서 시스템 백 엔드 환경에서 암호화 키에 대한 Sam Daily 승인을 받기 위한 요청이 생성되었음을 보여 줍니다. 이 작업은 서면 권한 부여를 얻은 다음 단계로 수행됩니다.

Jira 승인 티켓.

이는 Sam Daily 액세스 권한을 부여하라는 요청이 Jon Smith가 경영진의 승인을 받았다는 것을 보여줍니다. (변경 요청을 허용할 수 있는 충분한 권한이 있는 사람이 승인을 받아야 하며, 다른 개발자가 될 수 없습니다).

프로세스 흐름 차트.

이전에서는 이 프로세스에 대한 Jira의 워크플로를 보여 줍니다. 자동화되어 무시할 수 없는 승인 프로세스를 거치지 않는 한 완료로 추가할 수 있는 것은 없습니다.

Jira 승인 위원회.

프로젝트 보드는 이제 Sam Daily의 암호화 키 액세스에 대한 승인이 주어졌다는 것을 보여주고 있습니다. 다음 백로그는 Sam Daily의 요청 승인 및 작업을 수행하도록 할당된 사람을 보여줍니다.

Jira 승인 위원회.

이 컨트롤의 요구 사항을 충족하려면 이러한 모든 스크린샷 또는 컨트롤 요구 사항을 충족했음을 보여 주는 설명과 함께 적용할 수 있는 유사/동등한 증거를 표시해야 합니다.

예시 증거:

다음 예제에서는 프로덕션 DB에 대한 사용자에 대한 관리자 액세스 및 모든 권한 권한이 요청되었습니다. 요청이 이미지 오른쪽에 표시될 수 있는 대로 승인을 위해 전송되었으며 왼쪽에 표시된 대로 승인되었습니다.

Jira 승인 위원회.

다음 이미지는 액세스가 승인되고 완료된 대로 로그오프되었음을 나타냅니다.

Jira 승인 위원회.

의도

이 하위 지점의 의도는 문서화된 대로 데이터 및/또는 암호화 키 액세스가 구성되어 있는지 확인하는 것입니다.

지침:

샘플링된 개인에게 부여된 데이터 및/또는 암호화 키 액세스 권한을 보여주는 스크린샷을 통해 증거를 제공할 수 있습니다. 증거는 모든 데이터 위치를 포함해야 합니다.

예시 증거:

이 스크린샷은 교차할 사용자 "John Smith"에게 부여된 권한을 보여줍니다.

이전 컨트롤의 증명 정보에 따라 이 동일한 사용자에 대한 승인 요청에 대해 참조됩니다.

참고: 다음 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자 및 증거 검토를 위한 시간 및 날짜 스탬프가 필요합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.

Linux 쿼리 편집기.

컨트롤 번호 9

다음과 같은 증거를 제공합니다.

데이터가 공유되는 모든 타사 목록이 유지 관리됩니다.
데이터 공유 계약은 데이터를 소비하는 모든 타사와 함께 제공됩니다.

의도:

타사에서 Microsoft 365 데이터의 스토리지 또는 처리에 사용되는 경우 이러한 엔터티는 상당한 위험을 초래할 수 있습니다. 조직은 이러한 제3자가 데이터를 안전하게 저장/처리하고 GDPR에 따른 데이터 프로세서와 같은 법적 의무를 준수할 수 있도록 적절한 타사 실사 및 관리 프로세스를 개발해야 합니다.

조직은 다음 중 일부 또는 전부와 데이터를 공유하는 모든 타사 목록을 유지해야 합니다.

제공되는 서비스
공유되는 데이터
데이터가 공유되는 이유
주요 연락처 정보(예: 기본 연락처, 위반 알림 연락처, DPO 등)
계약 갱신/만료
법률/규정 준수 의무(예: GDPR, HIPAA, PCI DSS, FedRAMP 등)

지침:

Microsoft 365 데이터가 공유되는 모든 타사에 대해 자세히 설명하는 설명서를 제공합니다.

참고: 제3자가 사용하지 않는 경우 선임 리더십 팀의 구성원이 서면(이메일)으로 확인해야 합니다.

예시 증거:

데이터 공유 계약.

참고: - 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.

예시 증거:

다음 스크린샷은 Microsoft 365 데이터를 처리하는 데 사용되는 제3자가 없음을 확인하는 선임 리더십 팀의 구성원의 이메일 예제를 보여 줍니다.

CEO로부터 Email.

참고: - 이러한 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.

의도:

M365 데이터가 타사와 공유되는 경우 데이터가 적절하고 안전하게 처리되는 것이 중요합니다. 제3자가 필요에 따라 데이터를 처리하고 보안 의무를 이해하도록 데이터 공유 계약이 체결되어야 합니다. 조직 보안은 가장 약한 링크만큼 강력합니다. 이 제어의 목적은 제3자가 조직이 약한 링크가 되지 않도록 하기 위한 것입니다.

지침:

제3자와 함께 제공되는 데이터 공유 계약을 제공합니다.

예시 증거:

다음 스크린샷은 데이터 공유 계약의 간단한 예제를 보여줍니다.

데이터 공유 계약.

참고: 전체 계약은 스크린샷이 아닌 공유되어야 합니다.

개인 정보 보호

개인 정보 보호 규정 준수 및 정보 관리는 개인의 권리를 보호하고 책임 있는 데이터 처리를 보장하는 데 필수적입니다. organization 효과적인 개인 정보 시스템을 설정하려면 보유하고 있는 개인 데이터와 이러한 데이터를 처리하고 저장하는 목적을 알고 있어야 합니다. organization 정보의 흐름과 이를 처리하는 방법을 매핑하여 여러 가지 유형의 처리가 발생할 수 있음을 인식해야 합니다.

컨트롤 번호 10

organization PIM(개인 정보 관리) 시스템을 설정, 구현 및 유지 관리하나요?

시스템 기밀성 및 무결성을 위해 개인 정보 관리 노력이 유지되는 방식에 대한 정책 또는 기타 형태의 설명서/전산화된 시스템을 통해 리더십 약정을 유지합니다.
PII 프로세서 및 컨트롤러를 포함하여 시스템을 유지 관리하는 각 사용자의 역할, 책임 및 권한을 결정합니다.

의도:

이 시점의 목적은 '개인 정보 보호 문화'가 존재하고 효과적인 개인 정보 보호 거버넌스 프로그램을 통해 organization 리더십에 의해 지원되도록하는 것입니다. organization 경영진은 확립된 설명서와 프로세스를 통해 효과적인 개인 정보 보호 관리 시스템이 있음을 입증해야 하며, 프로세스는 organization 전략적 목표에 부합하며 organization의 컨텍스트 및 상황뿐만 아니라 개인 정보 관리 시스템이 비즈니스 프로세스 내에 포함되어 있는지 확인합니다.

지침:

이는 PIM(개인 정보 관리) 정책 및 절차를 설명하는 organization 확립된 설명서를 제공하여 입증됩니다. 인증 분석가는 이를 검토하여 컨트롤 내에서 제공된 모든 정보가 처리되는지 확인합니다.

예시 증거:

다음 스크린샷은 PIM 정책의 스냅샷을 보여 줍니다.

개인 정보 관리 정책 문서.

참고: ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

의도

책임은 organization 적절하고 효과적인 정책, 절차 및 프로세스를 구현하여 개인 데이터 처리와 관련된 위험을 최소화할 수 있도록 하는 데이터 보호법의 주요 원칙 중 하나입니다. 이러한 측정값은 처리 또는 전송되는 데이터의 양, 민감도 및 사용 중인 기술에 따라 달라질 수 있는 위험에 비례해야 합니다. 이를 위해 각 직원은 성공적인 구현을 보장하기 위해 개인 정보 관리 시스템의 다양한 요소를 담당하는 사람을 알고 있어야 합니다. 역할, 책임 및 기관을 명확하게 정의된 방식으로 요약하고 해당 역할을 적절하게 할당함으로써 organization 개인 정보 관리 시스템이 효과적인지 확인할 수 있습니다.

지침:

이는 각 관련자의 역할, 책임 및 권한을 설명하는 organization 확립된 설명서를 제공하여 입증될 것입니다. 인증 분석가는 이를 검토하여 컨트롤 내에서 제공된 모든 정보가 처리되는지 확인합니다.

예시 증거:

다음 스크린샷은 승인된 직원 목록이 포함된 정책의 섹션을 보여 주는 PIM 정책의 스냅샷을 보여 줍니다.

개인 정보 관리 정책 문서.

참고: ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

컨트롤 번호 11

다음을 보여 주는 프로세스의 증거를 제공합니다.

PII 최소화가 진행되고 있습니다.
PII 식별 해제 및 삭제는 처리 기간이 끝날 때 수행됩니다.
기밀성을 포함하여 PII 전송을 위한 컨트롤이 마련되어 있습니다.
한 국가/지역에서 다른 지역으로 PII를 전송하는 기록은 명시적인 동의를 가지고 존재합니다.

의도: PII

PII(개인 식별 정보) 최소화의 목적은 organization organization 컨텍스트 내에서 비즈니스 근거 내에서 특정 목적을 달성하는 데 필요한 최소한의 개인 데이터만 수집, 사용 및 보존하도록 하는 것입니다. 개인 데이터를 처리할 때 organization 목표/작업을 달성하는 데 필요한 최소 데이터 양을 식별하고 필요한 최소 데이터보다 더 이상 저장되지 않도록 해야 합니다. 불필요한 개인 데이터의 처리 및 저장을 최소화함으로써 organization 데이터 오용, 무단 액세스 및 데이터 침해와 관련된 위험 수준을 줄일 수 있습니다.

지침: PII

자동화된 플랫폼을 통해 개인 정보 사용을 최소화하는 데 사용되는 솔루션의 구성 설정을 통해 증거를 제공할 수 있으며, 수동 관리 프로세스인 경우 최소화 프로세스의 증거와 발생한 프로세스의 기록 증거를 분석가에게 제공하여 검토해야 합니다.

예시 증거: PII

다음 스크린샷은 해당 기간 내에 organization 내에서 수신된 모든 새 데이터를 검토하고 해당하는 경우 불필요한 것으로 간주되는 개인 정보가 제거되는 매월 모임이 예약되어 있음을 보여줍니다.

Outlook 되풀이 이벤트 미리 알림.

다음 스크린샷은 플랫폼 내에서 새 고객을 온보딩하는 데 사용되는 채워진 사용자 등록 양식의 예입니다.

새 고객 등록 양식.

후속 스크린샷은 PII 최소화 모임 및 검토에 따라 양식 내에서 수집된 중요한 정보 중 일부가 더 이상 서비스를 사용자에게 다시 제공할 필요가 없는 것으로 간주되었음을 보여 줍니다. 다음 이미지에서 심판의 PII와 이메일 주소가 제거되었습니다(각 organization 해당 정보를 보유하거나 제거하기 위한 비즈니스 정당성을 가질 것으로 예상됨).

새 고객 등록 양식.

참고: 이전은 한 가지 잠재적 시나리오의 예입니다. 이는 포괄적인 것이 아니며 증거를 제공할 때 PII를 최소화하는 프로세스를 명확하게 입증해야 하며 organization 특정 컨텍스트에 적용해야 합니다.

의도: 데이터 개인 정보

이 하위 지점의 의도는 다각적이고 여러 기술과 다양한 개념을 다루지만 전체 목표는 organization 데이터 개인 정보를 향상시켜 데이터 보호 규정을 준수하는 organization 위한 것입니다.

데이터에서 개인을 식별하는 데 사용할 수 있는 특정 정보를 제거하는 프로세스인 식별 해제부터는 전자 메일 주소, 생년월일 등과 같이 민감한 것으로 간주되는 모든 정보가 가명화 또는 마스킹과 같은 다양한 기술을 통해 개인과 직접 연결하는 데 사용할 수 없는 형식으로 변경/변환되도록 하기 위한 것입니다. 이 프로세스의 목적은 데이터의 유용성을 유지하는 것뿐만 아니라 데이터 오용, 무단 액세스 및 데이터 침해와 관련된 위험 수준을 줄이기 위한 것입니다.

조직은 처리 기간이 끝날 때 데이터 보존을 정의하고 불필요한 데이터를 삭제해야 합니다. 데이터가 정의된 데이터 보존 기간을 초과하면 데이터를 다시 구성하거나 복구할 수 없도록 안전하게 삭제해야 합니다. 필요한 데이터와 필요한 기간 동안 데이터를 유지하면 데이터 위반이 발생할 경우 organization 위험을 줄이는 데 도움이 됩니다. 이렇게 하면 데이터가 지나치게 긴 기간 동안 보존되거나 조기에 삭제되지 않으며, 둘 다 법적, 운영 또는 보안과 관련된 다양한 성격의 위험을 초래할 수 있습니다.

지침: 데이터 개인 정보

PII 데이터가 제어 요구 사항에 따라 익명화되고 삭제되도록 하는 데 사용되는 메커니즘 및/또는 기술의 구성 설정을 통해 증거를 제공할 수 있습니다.

증거 예: 데이터 개인 정보

다음 스크린샷에 표시된 예제에서는 템플릿 갤러리의 일부인 Azure Data Factory 기본 제공 데이터 익명화 템플릿을 사용하며 콘텐츠를 익명화하는 동안 텍스트 파일 집합을 한 위치에서 다른 위치로 이동할 수 있습니다. AZURE에 PII 익명화를 위한 데이터 팩터리가 있음을 보여 줍니다.

Azure 데이터 팩터리 dashboard.

다음 스크린샷은 PII 익명화 파이프라인의 구성을 보여 줍니다. 이 코드는 Azure App Service Presidio를 사용하여 각 파일을 Azure Blob Storage 구문 분석하고 저장하는 동안 Azure Data Factory 파이프라인에서 Presidio를 HTTP REST 엔드포인트로 호출하는 코드를 활용합니다.

Azure 데이터 팩터리 dashboard.

다음 스크린샷은 파이프라인 단계 및 논리를 보여 줍니다.

워크플로 파이프라인 그림.

마지막 스크린샷은 PII를 익명화하기 위해 파이프라인을 성공적으로 실행하는 방법을 보여 줍니다.

워크플로 파이프라인 그림.

참고: 이전은 한 가지 잠재적 시나리오의 예입니다. 이는 포괄적인 것이 아니며 증거를 제공할 때 PII를 익명화하는 프로세스를 명확하게 입증해야 하며 organization 특정 컨텍스트에 적용해야 합니다.

증거 예: 데이터 개인 정보

다음 스크린샷은 PII가 보관된 Azure의 스토리지 계정에 수명 주기 관리 정책을 사용하도록 설정하여 처리 기간이 끝날 때 PII 삭제를 해결하는 예제를 보여 줍니다.

Azure 수명 주기 관리 페이지.

다음 스크린샷은 데이터가 자동으로 삭제되는 미리 정의된 기간 동안 보존이 설정됨을 보여 줍니다.

Azure 수명 주기 관리 페이지.

참고: 이전은 한 가지 잠재적 시나리오의 예입니다. 이는 포괄적인 것이 아니며 증거를 제공할 때 PII 데이터 및 적용 가능한 특정 보존 기간을 삭제하는 프로세스를 명확하게 입증해야 하며 organization 특정 컨텍스트에 적용해야 합니다.

증거 예: 데이터 개인 정보

마지막 스크린샷은 SharePoint, OneDrive, 디바이스, 사서함 등과 같이 organization 내의 다양한 위치에서 PII 데이터 전송 및 스토리지에 대한 데이터 수명 주기 관리 보존 정책이 적용되어 있음을 보여 줍니다. 이 정책은 Microsoft Purview를 사용하여 사용하도록 설정됩니다. 미리 정의된 보존 기간이 경과하면 모든 PII를 자동으로 삭제하도록 보존 정책이 구성됩니다.

Microsoft Purview 수명 주기 관리 페이지.

의도: 컨트롤

이 하위 지점의 목적은 조직이 처리 및 전송 중에 PII를 보호하기 위한 적절한 기술 및 관리/운영 보호 장치를 마련하도록 하는 것입니다. 기밀성에 중점을 두는 것은 미사용 데이터 암호화, 문서화된 액세스 제어 목록 및 정기적인 감사와 같은 기술 및 관리 제어를 통해 무단 액세스 및 공개로부터 데이터를 보호하는 것을 의미합니다.

지침: 컨트롤

PII 데이터가 제어 요구 사항에 따라 보호되도록 하는 데 사용되는 보호 메커니즘의 구성 설정을 통해 증거를 제공할 수 있습니다. 이러한 메커니즘에는 액세스 제어, RBAC, 암호화, 데이터 손실 방지 등이 포함될 수 있습니다.

고지 사항: 제시된 예제는 PII가 보호되도록 컨트롤이 적용되는 몇 가지 잠재적 시나리오를 보여 줍니다. 보호 메커니즘의 유형은 organization 컨텍스트 및 PII 사용, 저장 방식에 따라 달라집니다.

예시 증거: 암호화

다음 예제에서는 PII가 보관되는 스토리지 위치에서 PII 암호화 및 사용자가 애플리케이션의 백 엔드에 저장된 개인 정보를 입력하는 웹 애플리케이션/플랫폼을 통해 전송하는 동안 암호화를 보여 줍니다.

스크린샷은 스토리지 위치에 기본적으로 암호화된 미사용 데이터가 있음을 보여 줍니다.

암호화가 기본적으로 사용되는 플랫폼에서 수행되지 않는 경우 및 사용자 고유의 암호화에 유의하세요.

키가 사용 중이면 해당 키가 적절하게 보호되고 이를 입증하기 위한 증거가 제공될 것으로 기대됩니다.

Azure 암호화 관리 페이지.

두 번째 스크린샷은 PII가 수집되는 애플리케이션에 대해 TLS1.2가 전송 중에 적용됨을 보여줍니다.

Azure 암호화 관리 페이지.

예시 증거: 액세스 제어

다음 스크린샷은 네트워킹 관점에서 보안 회사 네트워크인 권한 있는/승인된 IP 범위만 PII 스토리지 위치에 액세스할 수 있음을 보여 줍니다.

Azure 네트워킹 관리 페이지.

다음 스크린샷은 적격 할당이 있는 Azure PIM 및 사용자 목록의 예를 보여 줍니다. JIT(Just-In-Time) 액세스를 사용하면 사용자가 제한된 시간 동안 권한 있는 역할 또는 리소스에 일시적으로 액세스할 수 있으므로 권한 있는 사용자가 손상되거나 환경, 데이터 위치 등에 변경 내용이 도입될 위험이 줄어듭니다.

Microsoft Entra 관리 센터.

예시 증거: PII 전송 및 공개 방지

이러한 스크린샷은 조직이 단일 중앙 집중식 위치에서 DLP 정책을 관리할 수 있는 통합 플랫폼인 DLP(Microsoft Purview 데이터 손실 방지)를 보여줍니다.

아래에서 "영국 PII 데이터" 정책이 사용하도록 설정되어 있는지 확인할 수 있습니다. 이렇게 하면 사용자가 지원되는 웹 브라우저를 통해 액세스할 때 개인 전자 메일, 생성 AI 프롬프트, 소셜 미디어 사이트 등을 비롯한 특정 웹 사이트에 중요한 데이터를 제공하지 못하도록 할 수 있습니다. 이렇게 하면 모든 직장 디바이스/사용자가 조직 정책을 적용함에 따라 직원이 PII를 무단으로 공개하거나 기밀을 침해할 위험이 줄어듭니다.

Microsoft Purview 정책 설정.

다음 스크린샷은 적용되는 scope 포함하여 정책에 대한 포괄적인 개요를 제공합니다. 정책은 SharePoint, 디바이스, OneDrive 등과 같은 위치에 있는 모든 계정으로 설정됩니다.

Microsoft Purview 정책 설정.

이전 및 다음 스크린샷은 사용자가 PII(개인 식별 정보)와 같은 중요한 정보를 복사하고 붙여넣지 못하도록 DLP 정책이 설정되어 있음을 보여 줍니다.

organization 내부 데이터베이스에서 지원되는 브라우저의 개인 전자 메일 계정, 챗봇 및 소셜 미디어 사이트로 이동합니다.

Microsoft Purview 정책 설정.

의도: 레코드

이 하위 지점의 의도는 두 가지입니다. 다양한 국가에서 개인 식별 정보를 전송하는 데는 다양한 법적 요구 사항을 탐색하는 것과 관련되므로 법적 규정 준수 및 책임을 보장하는 동시에 데이터 거버넌스 및 데이터 보호를 용이하게 하기 위해 효과적인 레코드 관리가 수행되도록 합니다. PII 전송을 시작하기 전에 organization 자신이 속한 데이터 주체로부터 명시적 동의를 받아야 하며, 개인에게 전송, 전송 목적 및 관련 위험에 대해 알려야 한다고 말했습니다. 획득되는 동의 레코드는 전송 권한 부여의 유효성을 검사합니다. 전송 레코드에는 전송, 위험 평가, 데이터 보호 영향 및 보존 기간에 대한 추가 세부 정보도 포함되어야 합니다.

지침: 레코드

PII 전송 레코드 및 명시된 동의 레코드에 대해 제공할 수 있는 증거는 전송 프로세스 및 레코드 관리가 organization 수준에서 구현되는 방법에 따라 달라집니다. 여기에는 서비스의 플랫폼, 사용 약관 또는 각 사용자가 입력한 동의 양식을 통해 동의를 얻을 수 있는지 여부가 포함될 수 있습니다. 제공된 증거는 기간 동안 완료된 전송의 기록 레코드가 존재하고 이를 추적하는 방법과 명시적 동의가 획득되는 기록을 보여줘야 합니다.

예시 증거: 레코드

다음 스크린샷은 organization 서비스 사용자 중 한 명이 동의 양식에 입력한 예제를 보여 줍니다. 사용자가 조건에 대한 명시적 동의, 승인 및 이해를 제공한 것을 볼 수 있습니다.

동의 양식 문서입니다.

다음 스크린샷은 PII 전송의 기록 레코드가 존재하며 교환되는 특정 PII 데이터, 전송 목적, 원본 국가, 대상 국가, 전송 중인 데이터 보호, 승인 등에 대한 세부 정보를 포함합니다.

PII 전송에 대한 Confluence 레코드입니다.

참고: 이전은 하나의 잠재적 시나리오의 예이며, 절대로 포괄적이며 증거를 제공할 때 PII 데이터, 레코드 관리 등을 전송하는 프로세스를 명확하게 보여야 하며 organization 특정 컨텍스트에 적용해야 합니다.

대부분의 조직은 잠재적으로 유럽 시민(데이터 주체) 데이터인 데이터를 처리합니다. 모든 데이터 주체의 데이터가 처리되는 경우 조직은 GDPR(일반 데이터 보호 규정)을 충족해야 합니다. 이는 데이터 컨트롤러(해당 데이터를 직접 캡처하는 경우) 또는 데이터 프로세서(데이터 컨트롤러를 대신하여 이 데이터를 처리하고 있습니다)에 모두 적용됩니다. 이 섹션에서는 전체 규정을 다루지는 않지만 GDPR의 핵심 요소 중 일부를 다루어 organization GDPR을 심각하게 받아들이고 있다는 확신을 얻을 수 있습니다.

컨트롤 번호 12

다음을 보여주는 증거를 제공합니다.

데이터 주체는 SAR을 올릴 수 있습니다.
사용자(ISV)가 SAR 요청에 응답할 때 데이터 주체 데이터의 모든 위치를 식별할 수 있는지 확인합니다.
기간 동안 롤링 백업이 제거될 때 SAR을 통해 데이터 제거를 요청하는 클라이언트를 제거할 수 있는 백업에 대한 보존 기간이 있습니다(가장 오래된 백업 삭제/다시 쓰기의 수명 주기).

의도:

GDPR에는 데이터 주체의 데이터를 처리하는 조직에서 충족해야 하는 특정 의무가 포함됩니다. 조직에서 SAR(주체 액세스 요청)을 관리해야 하는 의무는 제12조 12.3항에 따라 데이터 컨트롤러에게 요청에 응답하기 위해 SAR 수신으로부터 1개월을 부여하는 조항에 포함되어 있습니다. 확장은 필요한 경우 추가로 2개월 동안 허용되며, 그렇게 할 근거가 있는 경우에만 허용됩니다. organization 데이터 프로세서 역할을 하는 경우에도 고객(데이터 컨트롤러)이 SAR 의무를 이행할 수 있도록 지원해야 합니다.

지침:

SAR을 처리하기 위한 문서화된 프로세스를 제공하세요. 예시 증거:

다음 예제에서는 SAR을 처리하기 위한 문서화된 프로세스를 보여 있습니다.

주체 액세스 요청 절차 설명서.

참고: 이 스크린샷은 ISV가 실제 지원 정책/절차 설명서를 공유하기를 기대하는 정책/프로세스 문서를 보여줍니다.

의도:

이 컨트롤의 목적은 organization 모든 데이터 주체의 데이터를 식별하는 강력한 메커니즘을 갖도록 하기 위한 것입니다. 모든 데이터 스토리지가 잘 문서화되었거나 다른 도구를 사용하여 모든 데이터가 SAR 프로세스의 일부로 배치되도록 하기 때문에 수동 프로세스일 수 있습니다.

지침:

모든 데이터 위치 목록과 문서화된 프로세스를 통해 모든 데이터 위치에서 데이터를 검색하는 방법으로 증거를 제공할 수 있습니다. 여기에는 데이터를 검색하는 데 필요한 명령, 즉 SQL 위치가 포함된 경우 특정 SQL 문이 자세히 설명되어 데이터가 제대로 검색되도록 하는 명령이 포함됩니다.

예시 증거:

다음 스크린샷은 데이터를 찾을 방법을 보여 주는 이전 SAR 절차의 코드 조각입니다.

주체 액세스 요청 절차 설명서.

다음 4개의 이미지는 ISV 데이터 위치를 쿼리하는 방법을 보여 줍니다. Storage Explorer SAR 요청을 준수하기 위해 스토리지에서 제거해야 하는 파일 또는 Blob으로 드릴다운하는 데 사용되었습니다.

참고: 이러한 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자와 증거 검토를 위한 시간 및 날짜 스탬프가 있어야 합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.

Microsoft Azure Storage 계정 페이지.

Microsoft Azure 리소스 그래프 탐색기.

이 쿼리는 사용 중인 스토리지 계정을 확인합니다. Resource Graph Explorer(Kusto) 또는 PowerShell을 사용하여 스토리지, Blob 및/또는 파일을 쿼리하고 제거할 수 있습니다(다음 참조).

Kusto 탐색기.

Powershell 쿼리.

참고: - 이 섹션의 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 화면 스크린샷이어야 합니다.

Microsoft Azure Storage 탐색기.

다음 이미지는 제거해야 하는 클라이언트의 Blob 컨테이너 내에서 발견된 데이터를 보여 줍니다. 다음은 Blob에서 정보를 삭제하거나 일시 삭제하는 작업을 보여 줍니다.

Microsoft Azure Storage 탐색기.

참고: 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자와 증거 검토를 위한 시간 및 날짜 스탬프가 있어야 합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.

의도:

이 컨트롤은 SAR에 따라 데이터 제거를 수용하는 방식으로 설계된 백업에 대한 공식적인 보존 기간이 있음을 보여주기 위한 것입니다. 보존 프레임워크는 정의된 기간 동안 이전 백업을 단계적으로 중단하여 SAR로 인해 제거된 모든 데이터가 궁극적으로 모든 백업에서 지워지도록 해야 합니다. 이는 organization 백업 및 데이터 보존 관행을 SAR에서 발생하는 의무와 일치시켜 삭제 권리에 관한 규제 요구 사항을 충족하는 데 중요합니다.

지침:

백업이 수행되는 기간 및 방법론을 보여 주는 백업 구성 설정을 보여 주는 스크린샷을 통해 증거를 제공할 수 있습니다. 백업 빈도 기간에 중점을 두어야 합니다.

예시 증거:

다음 스크린샷은 관리되는 instance Azure Database for MySQL의 구성 설정 조각입니다.

Microsoft Azure SQL 개요.

스크린샷에서 백업 보존 기간이 28일로 설정된 것을 볼 수 있습니다.

Microsoft Azure SQL 개요.

백업 섹션에 따르면 유연한 서버의 백업은 서버를 만든 직후에 예약되고 스냅샷 백업이 매일 한 번 수행되는 첫 번째 스냅샷 백업을 기반으로 스냅샷.

백업 빈도와 결합된 28일 백업 보존은 SAR이 처리될 때 모든 사용자 데이터가 제거될 때까지 보존 기간에 적용되는 대로 롤링 백업이 최대 27일 동안 계속되며 감소한다는 것을 의미합니다.

컨트롤 번호 13

다음과 같이 필요한 모든 요소를 포함해야 하는 개인 정보 보호 알림을 제공하세요.

엔터티 세부 정보(이름, 주소 등)
처리 중인 개인 데이터의 형식에 대한 세부 정보입니다.
개인 데이터가 보관되는 기간을 자세히 설명합니다.
개인 데이터 처리의 적법성에 대한 세부 정보입니다.
데이터 주체의 권한에 대한 세부 정보:
- 알릴 권리
- 데이터 주체에 의한 액세스 권한
- 삭제할 권리
- 처리 제한에 대한 권리
- 데이터 이식성에 대한 권리
- 개체에 대한 권한
- 프로파일링을 포함하여 자동화된 의사 결정과 관련된 권한

의도:

GDPR 제13조에는 개인 데이터를 얻을 때 데이터 주체에게 제공해야 하는 특정 정보가 포함되어 있습니다. 이 제어의 목적은 조직 데이터 개인 정보 보호 알림이 제13조에 포함된 주요 정보 중 일부를 데이터 주체에게 제공하는 것입니다.

지침:

이는 일반적으로 데이터 개인 정보 보호 알림을 제공하여 제공됩니다. 인증 분석가는 이를 검토하여 컨트롤 내에 제공된 모든 정보가 데이터 개인 정보 보호 알림에 포함되어 있는지 확인합니다.

예시 증거:

다음 스크린샷은 개인 정보 취급 방침의 스냅샷을 보여 줍니다.

개인 정보 고지 문서.

개인 정보 고지의 이미지는 GDPR 제13조가 포함된 온라인 개인 정보 취급 방침의 예를 보여 줍니다.

개인 정보 고지 문서.

다음은 이전에 표시된 개인 정보 보호 알림과 함께 사용할 수 있는 데이터 보호 정책입니다.

데이터 보호 정책 문서입니다.

Azure 정책 할당 페이지.

Azure의 이전 이미지는 Azure가 백 엔드 환경에 저장된 데이터에 대한 GDPR의 규정 준수 요구 사항을 충족하도록 구성된 방법을 보여 줍니다. 정책(Azure Blueprints에서 사용자 지정하거나 빌드할 수 있음)을 사용하면 ISV가 클라이언트의 데이터가 올바르게 저장되고 지정된 메트릭에서만 액세스할 수 있도록 할 수 있습니다. 또한 경고는 규정 준수를 보장하도록 설정되며 규정 준수 관리자 dashboard 비규격 데이터 또는 사용자 액세스를 표시합니다.

참고: 이전 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자와 증거 검토를 위한 시간 및 날짜 스탬프가 있어야 합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.

HIPAA(건강 보험 이식성 및 책임법)

1996년 건강 보험 이식성 및 책임법(HIPAA)은 미국 시민 및 의료 기관에 적용되는 연방 법률입니다. 이 법안은 미국 시민의 의료 데이터를 처리하는 미국 이외의 모든 조직에도 적용된다는 점에 유의해야 합니다. 법안의 도입은 특정 건강 정보의 개인 정보 보호 및 보안을 보호하는 규정을 개발하기 위해 미국 보건 복지부 (HHS)의 장관을 위임했다. 일부 조직은 잠재적으로 보호되는 ePHI(건강 정보)인 데이터를 처리할 수 있습니다. 즉, 전자 미디어에 의해 전송되거나, 전자 미디어에서 유지 관리되거나, 다른 형태 또는 매체로 전송되거나 유지 관리되는 개별 식별 가능한 건강 정보를 의미합니다. 모든 데이터 주체의 상태 데이터가 처리되는 경우 조직은 HIPAA를 충족해야 합니다.

HIPAA에는 '개인 정보 보호 규칙' 또는 특정 건강 정보 보호를 위한 국가 표준을 간략하게 설명하는 개인 식별 가능한 건강 정보의 개인 정보 보호 표준과 '보안 규칙'이라고도 하는 전자 보호 건강 정보 보호에 대한 '보안 표준'의 두 가지 법률이 있습니다. 후자는 전자 형태로 보유되거나 전송되는 특정 건강 정보를 보호하기 위한 국가 보안 표준 집합을 설정합니다.

개략적인 개요에서 '보안 규칙'은 '개인 정보 규칙'에서 제공하는 보호의 실질적인 구현입니다. "적용 대상 엔터티"가 개인의 "전자 보호 건강 정보"(e-PHI)의 보안을 보장하기 위해 구현해야 하는 기술 및 비기술적 조치에 대해 간략하게 설명합니다. 이 섹션에서는 전체 규정을 다루지는 않지만 HIPAA의 주요 요소 중 일부를 다루어 organization 요구 사항을 준수하고 organization 처리하는 건강 정보를 보호하고 있다는 확신을 얻을 수 있습니다.

컨트롤 번호 14

다음을 입증할 수 있는 증거를 제공하세요.

직원, 계약자 등에 대한 organization 내에서 HIPAA 및 HIPAA 처리를 위한 정책이 있습니다.
ISV는 ePHI가 생성, 수신, 유지 관리 또는 전송하는 ePHI의 기밀성, 무결성 및 가용성을 보장합니다.
ePHI의 보안 또는 무결성에 대해 합리적으로 예상되는 위협 및 위험으로부터 보호합니다.

의도:

이 하위 지점의 목적은 조직이 건강 정보 관리, 비상 사태 및 서비스 중단 처리, 직원 건강 정보 및 교육에 대한 직원 액세스에 대한 표준 절차 역할을 하는 프로토콜을 수립하도록 하는 것입니다. 또한 조직은 HIPAA 보안 프로그램의 일환으로 이러한 관리 안전 장치를 유지 관리하고 간략하게 설명해야 합니다. 이는 HIPAA 규정을 준수하는 데 중요한 측면입니다.

지침:

이는 HIPAA 정책 및 절차를 설명하는 organization 확립된 설명서를 제공하여 입증될 것입니다. 인증 분석가는 이를 검토하여 컨트롤 내에서 제공된 모든 정보가 처리되는지 확인합니다.

예시 증거:

스크린샷은 HIPAA 정책의 스냅샷을 보여줍니다. 참고: ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

HIPAA 정책 문서입니다.

참고: ISV가 실제 포괄적인 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

의도:

이 하위 지점의 의도를 이해하고 보안 규칙을 준수하기 위해 "적용된 엔터티"는 먼저 § 164.304에 따라 기밀성, 무결성 및 가용성에 대한 조건이 정의되는 방법을 알고 있어야 합니다.

기밀성: "데이터 또는 정보가 허가되지 않은 사람 또는 프로세스에 공개되거나 공개되지 않는 속성"
무결성: "데이터 또는 정보가 무단으로 변경되거나 삭제되지 않은 속성"
가용성: "권한 있는 사람이 요청 시 데이터 또는 정보에 액세스할 수 있고 사용할 수 있는 속성."

이 요구 사항의 목적은 조직이 IT 인프라 내에서 액세스, 감사, 무결성 및 전송 제어와 같은 기술 안전 장치/조치를 구현하여 ePHI 기밀성을 보장하면서 권한 있는 사용자에게 무결성 및 가용성을 유지하는 것입니다.

지침:

ePHI 데이터가 제어 요구 사항에 따라 보호되도록 하는 데 사용되는 보호 메커니즘의 구성 설정을 통해 증거를 제공할 수 있습니다. 이러한 메커니즘에는 액세스 제어, 응급 액세스 절차, RBAC, 암호화 등이 포함될 수 있습니다.

예시 증거: 액세스 및 무결성 제어

다음 스크린샷은 ePHI 스토리지 위치를 처리할 수 있는 권한이 있는 개인의 권한 있는 액세스 목록이 존재하며 HIPAA 정책 문서 내에서 유지 관리됨을 보여 줍니다. 또한 승인된 인벤토리 목록 다음의 스크린샷에서는 관리자 및 데이터베이스 유지 관리 분석가만 클러스터에서 읽고 쓸 수 있는 클러스터 전체에서 제한된 쓰기 액세스 권한이 있음을 관찰할 수 있습니다.

HIPAA 정책 문서입니다.

Atlas Mongo의 ePHI 스토리지 데이터베이스 중 하나에서 찍은 다음 스크린샷은 권한 있는 사용자만 액세스 권한을 문서화하고 모든 계정에 책임을 보장하기 위한 고유한 사용자 ID가 있음을 보여 줍니다.

첫 번째 스크린샷은 ePHI에 대한 기본 스토리지 위치/데이터베이스 클러스터를 보여줍니다.

MongoDB 클라우드 클러스터 페이지.

두 번째 스크린샷은 승인된 사용자에게 역할 및 액세스 권한만 문서화되어 있음을 보여 줍니다.

MongoDB 클라우드 데이터베이스 페이지.

다음 두 스크린샷은 할당된 각 역할과 위의 액세스 승인에 부합하는 모든 관련 권한에 대한 보다 세부적인 보기를 보여 줍니다.

MongoDB 클라우드 데이터베이스 페이지.

각 사용자 지정 역할에는 액세스 권한 및 scope 집합이 있습니다.

MongoDB 클라우드 데이터베이스 페이지.

마지막으로 다음 스크린샷은 네트워킹 관점에서 보안 회사 네트워크인 권한 있는 IP 범위만 클러스터에 액세스할 수 있음을 보여 줍니다.

MongoDB 클라우드 네트워크 페이지.

예시 증거: 감사 컨트롤

이러한 스크린샷은 로깅 및 경고가 데이터베이스 클러스터에 대해 구현되었음을 보여 줍니다. 첫 번째 스크린샷은 경고가 사용하도록 설정되어 있음을 보여줍니다. 제공된 증명 정보에는 organization 필요/구현에 따라 설정된 경고 규칙도 표시됩니다. 두 번째 스크린샷은 데이터베이스 감사가 사용하도록 설정되어 있음을 보여줍니다.

MongoDB 클라우드 클러스터 페이지.

MongoDB 클라우드 데이터베이스 페이지.

다음 스크린샷은 기록 중인 데이터베이스 클러스터에 대한 액세스 기록을 보여줍니다. 경고가 설정되고 감사 로그를 기반으로 하며 미리 정의된 조건을 충족하지 않는 무단 액세스는 경고를 트리거합니다.

MongoDB 클라우드 데이터베이스 페이지.

마지막 두 스크린샷은 데이터베이스 클러스터에 대한 감사 로그가 생성되고 분석을 위해 로그를 내보낼 수 있음을 보여 줍니다.

MongoDB 클라우드 데이터베이스 페이지.

MongoDB 클라우드 로그 다운로드.

분석할 감사 로그에 대한 프로세스가 있으며 검토 프로세스의 증거도 제공해야 합니다. 프로그래밍 방식으로 수행되는 경우 사용된 플랫폼/로깅 솔루션에 대한 로그 수집의 구성 설정 스크린샷과 검토를 위해 규칙의 스크린샷을 제공해야 합니다.

예시 증거: 암호화 및 전송 제어

다음 스크린샷은 스토리지 위치에 기본적으로 암호화된 미사용 데이터가 있음을 보여 줍니다. 기본적으로 사용되는 플랫폼에서 암호화를 수행하지 않고 사용자 고유의 암호화 키를 사용하는 경우 해당 키가 적절하게 보호되고 이를 입증하기 위한 증거가 제공됩니다.

MongoDB 클라우드 데이터베이스 페이지.

다음 두 스크린샷은 스토리지 위치에 기본적으로 암호화된 전송 중인 데이터가 있음을 보여 줍니다. 첫 번째 스크린샷은 데이터 API가 '읽기 및 쓰기' 권한으로 사용하도록 설정되어 있음을 보여 줍니다.

MongoDB 클라우드 데이터베이스 페이지.

엔드포인트의 SSL 검사는 전송 중인 데이터가 TLS 1.2를 통해 암호화되었음을 보여줍니다.

Qualys SSl 보고서.

예시 증거: 가용성 및 복구 제어

다음 스크린샷은 가용성을 보장하기 위해 데이터베이스 클러스터가 세 지역에 복제되는 것을 보여 줍니다. 이 작업은 기본적으로 Mongo Atlas에서 수행됩니다. 또한 백업이 활성화되고 활성화되어 있습니다.

MongoDB 클라우드 데이터베이스 페이지.

다음 스크린샷은 스냅샷 이미 생성되었음을 보여 주는 클러스터의 백업 dashboard 보여 줍니다.

MongoDB 클라우드 데이터베이스 페이지.

다음 두 스크린샷은 PIT(특정 시점)에 예약된 백업을 수행하기 위한 백업 정책이 마련되어 있음을 보여 줍니다.

MongoDB 클라우드 데이터베이스 페이지.

다음은 스냅샷과 PIT(특정 시점 복원)에 대한 보존 정책이 있음을 나타냅니다.

MongoDB 클라우드 데이터베이스 페이지.

의도:

이 하위 지점의 의도는 "적용된 엔터티"가 엔터티의 크기, 조직 구조 및 특정 위험 및 위험에 대한 욕구에 적합한 정책, 절차 및 기술 솔루션을 구현할 수 있도록 유연성과 확장성을 보장하기 위해 개발된 보안 규칙과 일치합니다. 실용적인 관점에서 볼 때 이는 구현된 적절한 보안 조치가 "적용 대상 엔터티" 비즈니스의 특성과 규모 및 리소스에 따라 달라짐을 의미합니다.

모든 organization 포괄적인 위험 분석을 수행하여 전자 PHI의 기밀성, 무결성 및 가용성에 대한 잠재적 위험 및 취약성을 파악하는 것이 중요합니다. 이러한 위험 분석을 통해 조직은 적절한 보안 제어를 구현하여 이러한 식별된 위험을 완화할 수 있습니다.

지침:

위험 분석 출력을 통해 증거를 제공할 수 있습니다. 온라인 플랫폼을 통해 위험 분석을 수행하고 유지 관리하는 경우 전체 출력의 스크린샷을 제공해야 합니다.

예시 증거:

다음 스크린샷은 위험 평가 프로세스의 스냅샷을 보여 줍니다. 그런 다음, ePHI를 보호하기 위해 컨트롤이 올바르게 구현되고 작동하는 정도를 결정하기 위해 수행된 위험 분석이 뒤따릅니다. 두 번째 스크린샷은 위험 평가에서 확인된 위험에 대한 위험 분석과 위험 수준을 줄이기 위해 구현된 보상 제어 및 완화를 보여줍니다.

예제 1 – HIPAA 정책 및 수행된 위험 분석 내의 위험 평가 프로세스 스냅샷

HIPAA 정책 문서입니다.

참고: 이 스크린샷은 위험 분석 문서의 스냅샷 보여 줍니다. 이것은 단지 예일 뿐이며 ISV가 실제 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.

예제 2 - HIPAA 정책 및 수행된 위험 분석 내의 위험 평가 프로세스 스크린샷(Confluence Cloud Platform에서 유지 관리됨)

Confluence HIPAA 정책 페이지.

두 번째 스크린샷은 위험 평가에서 확인된 위험에 대한 위험 분석과 위험 수준을 줄이기 위해 구현된 보상 제어 및 완화를 보여줍니다. Confluence 클라우드 플랫폼에서 이 존재하고 유지 관리되는 것을 볼 수 있습니다.

Confluence 위험 분석 보고서.

컨트롤 번호 15

귀하(ISV)에 대한 증거를 제공해 주세요.

개인 정보 보호 규칙에서 허용하지 않는 이러한 정보의 합리적으로 예상되는 사용 또는 공개로부터 보호합니다. 및
직원의 보안 규칙 준수를 보장합니다.
164..308(a)(7)(ii)(A) 및 164.308(a)(7)(ii)(B)) 미만의 데이터 백업 및 재해 복구 계획입니다.

의도

개인 정보 보호 규칙은 법의 적용을 받는 PHI(보호된 건강 정보)의 일부를 정의하고 PHI의 부적절한 사용 및 공개를 금지합니다. 이 하위 지점의 의도는 organization e-PHI의 액세스 및 사용을 승인된 목적을 위해 필요한 사용자로만 제한해야 하며, 필요한 최소 규칙을 준수해야 하며, 이를 위해서는 의도한 목적을 달성하는 데 필요한 최소 양의 e-PHI만 사용하거나 공개해야 합니다.

ePHI 사용을 제한하고 ePHI 공개 위험을 줄이기 위해 기술 및 관리 보호 조치의 조합이 마련되어 있어야 합니다.

지침:

제공된 증거는 e-PHI를 보호하는 데 사용 중인 기술 및 메커니즘과 organization 제어가 이러한 데이터의 액세스 및 이동에 검사 방법을 보여줘야 합니다.

예시 증거:

다음 스크린샷은 조직이 단일 중앙 집중식 위치에서 DLP 정책을 관리할 수 있는 통합 플랫폼인 DLP(Microsoft Purview 데이터 손실 방지)를 보여 줍니다.

아래에서 "미국 HIPAA 고급" 정책이 사용하도록 설정되어 있음을 확인할 수 있으며, 이는 사용자가 지원되는 웹 브라우저를 통해 액세스할 때 개인 전자 메일, 생성 AI 프롬프트, 소셜 미디어 사이트 등을 비롯한 중요한 데이터를 특정 웹 사이트에 붙여넣지 못하도록 하는 기능을 제공합니다.