데이터 분류에 대한 권장 사항

Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.

이 가이드에서는 데이터 분류에 대한 권장 사항을 설명합니다. 대부분의 워크로드는 다양한 유형의 데이터를 저장합니다. 모든 데이터가 똑같이 중요한 것은 아닙니다. 데이터 분류를 사용하면 민감도 수준, 정보 유형 및 규정 준수 scope 따라 데이터를 분류하여 올바른 수준의 보호를 적용할 수 있습니다. 보호에는 액세스 제어, 다양한 정보 유형에 대한 보존 정책 등이 포함됩니다. 데이터 분류를 기반으로 하는 실제 보안 컨트롤은 이 문서에서 scope 않지만 organization 설정한 이전 기준에 따라 데이터를 분류하는 권장 사항을 제공합니다.

정의

주요 디자인 전략

데이터 분류는 종종 레코드 시스템 및 해당 기능을 빌드하는 데 중요한 연습입니다. 분류는 또한 보안 보증의 크기를 올바르게 조정하는 데 도움이 되며 심사 팀이 인시던트 대응 중에 검색을 수행하는 데 도움이 됩니다. 디자인 프로세스의 필수 구성 요소는 데이터를 기밀, 제한, 공용 또는 기타 민감도 분류로 처리해야 하는지 여부를 명확하게 이해하는 것입니다. 또한 데이터가 여러 환경에 분산될 수 있으므로 데이터가 저장되는 위치를 결정하는 것도 중요합니다.

데이터를 찾으려면 데이터 검색이 필요합니다. 이러한 지식이 없으면 대부분의 디자인은 보안 요구 사항을 충족하거나 제공하지 않을 수 있는 중간 접근 방식을 채택합니다. 데이터를 과도하게 보호하여 비용과 성능 비효율성을 초래할 수 있습니다. 또는 충분히 보호되지 않아 공격 표면에 추가될 수 있습니다.

데이터 분류는 종종 번거로운 연습입니다. 데이터 자산을 검색하고 분류를 제안할 수 있는 도구를 사용할 수 있습니다. 하지만 도구에만 의존하지 마세요. 팀 구성원이 부지런히 연습을 수행하는 프로세스를 마련합니다. 그런 다음 도구를 사용하여 실제적인 경우 자동화합니다.

이러한 모범 사례와 함께 잘 설계된 데이터 분류 프레임워크 Create 참조하세요.

organization 정의 분류 이해

분류 는 데이터 분류에 대한 계층적 묘사입니다. 분류 조건을 나타내는 명명된 엔터티가 있습니다.

일반적으로 분류 또는 분류 정의에 대한 범용 표준은 없습니다. 이는 데이터를 보호하기 위한 organization 동기에 의해 좌우됩니다. 분류는 규정 준수 요구 사항, 워크로드 사용자에 대해 약속된 기능 또는 비즈니스 요구 사항에 따라 구동되는 기타 기준을 캡처할 수 있습니다.

다음은 민감도 수준, 정보 유형 및 규정 준수 scope 대한 몇 가지 분류 레이블 예제입니다.

워크로드 소유자는 organization 사용하여 잘 정의된 분류를 제공합니다. 모든 워크로드 역할은 민감도 수준의 구조, 명명법 및 정의에 대한 공유된 이해가 있어야 합니다. 사용자 고유의 분류 시스템을 정의하지 마세요.

분류 scope 정의

대부분의 조직에는 다양한 레이블 집합이 있습니다.

각 민감도 수준에 대해 scope 및 scope 없는 데이터 자산 및 구성 요소를 명확하게 식별합니다. 결과에 대한 명확한 목표가 있어야 합니다. 목표는 더 빠른 심사, 가속화된 재해 복구 또는 규제 감사일 수 있습니다. 목표를 명확하게 이해하면 분류 작업의 크기를 올바르게 조정합니다.

이러한 간단한 질문으로 시작하고 시스템 복잡성에 따라 필요에 따라 확장합니다.

• 데이터 및 정보 형식의 원본은 무엇인가요?
• 액세스에 따라 예상되는 제한 사항은 무엇인가요? 예를 들어 공개 정보 데이터, 규정 또는 기타 예상 사용 사례인가요?
• 데이터 공간은 무엇인가요? 데이터는 어디에 저장되나요? 데이터는 얼마나 오래 보존해야 하나요?
• 아키텍처의 어떤 구성 요소가 데이터와 상호 작용합니까?
• 데이터는 시스템을 통해 어떻게 이동하나요?
• 감사 보고서에 필요한 정보는 무엇인가요?
• 사전 프로덕션 데이터를 분류해야 합니까?

데이터 저장소의 인벤토리 가져오기

기존 시스템이 있는 경우 scope 있는 모든 데이터 저장소 및 구성 요소의 인벤토리를 가져옵니다. 반면에 새 시스템을 디자인하는 경우 아키텍처의 데이터 흐름 차원을 만들고 분류 정의당 초기 분류를 만듭니다. 분류는 시스템 전체에 적용됩니다. 구성 비밀 및 비보안으로 분류하는 경우와는 분명히 다릅니다.

scope 정의

scope 정의할 때 세분화되고 명시적이어야 합니다. 데이터 저장소가 테이블 형식 시스템이라고 가정합니다. 테이블 수준 또는 테이블 내의 열에서도 민감도를 분류하려고 합니다. 또한 데이터 처리에 관련되거나 부분이 있을 수 있는 비데이터 저장소 구성 요소로 분류를 확장해야 합니다. 예를 들어 매우 중요한 데이터 저장소의 백업을 분류했나요? 사용자가 중요한 데이터를 캐싱하는 경우 scope 캐싱 데이터 저장소인가요? 분석 데이터 저장소를 사용하는 경우 집계된 데이터는 어떻게 분류되는가?

분류 레이블에 따라 디자인

분류는 아키텍처 결정에 영향을 줍니다. 가장 확실한 영역은 다양한 분류 레이블을 고려해야 하는 세분화 전략입니다.

예를 들어 레이블은 트래픽 격리 경계에 영향을 줍니다. TLS(엔드투엔드 전송 계층 보안)가 필요한 중요한 흐름이 있을 수 있지만 HTTP를 통해 다른 패킷을 보낼 수 있습니다. 메시지 브로커를 통해 전송되는 메시지가 있는 경우 특정 메시지에 서명해야 할 수 있습니다.

미사용 데이터의 경우 수준은 암호화 선택에 영향을 줍니다. 이중 암호화를 통해 매우 중요한 데이터를 보호하도록 선택할 수 있습니다. 애플리케이션 비밀마다 다양한 수준의 보호를 통해 제어해야 할 수도 있습니다. 더 높은 제한을 제공하는 HSM(하드웨어 보안 모듈) 저장소에 비밀을 저장하는 것을 정당화할 수 있습니다. 또한 규정 준수 레이블은 올바른 보호 표준에 대한 결정을 지시합니다. 예를 들어 PCI-DSS 표준은 HSM에서만 사용할 수 있는 FIPS 140-2 수준 3 보호를 사용해야 합니다. 다른 경우에는 다른 비밀이 일반 비밀 관리 저장소에 저장되는 것이 허용될 수 있습니다.

사용 중인 데이터를 보호해야 하는 경우 기밀 컴퓨팅을 아키텍처에 통합하는 것이 좋습니다.

분류 정보는 시스템을 통해 워크로드의 구성 요소 간에 전환할 때 데이터와 함께 이동해야 합니다 . 기밀로 레이블이 지정된 데이터는 상호 작용하는 모든 구성 요소에서 기밀로 처리해야 합니다. 예를 들어 모든 종류의 애플리케이션 로그에서 개인 데이터를 제거하거나 난독 처리하여 개인 데이터를 보호해야 합니다.

분류는 데이터를 노출하는 방식으로 보고서 디자인에 영향을 줍니다. 예를 들어 정보 형식 레이블에 따라 정보 형식 레이블의 결과로 난독 처리에 대한 데이터 마스킹 알고리즘을 적용해야 합니까? 원시 데이터와 마스킹된 데이터에 대한 가시성이 있어야 하는 역할은 무엇입니까? 보고에 대한 규정 준수 요구 사항이 있는 경우 데이터는 규정 및 표준에 어떻게 매핑되는가? 이러한 이해가 있는 경우 특정 요구 사항 준수를 입증하고 감사자에 대한 보고서를 생성하는 것이 더 쉽습니다.

또한 데이터 보존 및 서비스 해제 일정과 같은 데이터 수명 주기 관리 작업에 영향을 줍니다.

쿼리에 대한 분류 적용

식별된 데이터에 분류 레이블을 적용하는 방법에는 여러 가지가 있습니다. 메타데이터와 함께 분류 스키마를 사용하는 것이 레이블을 나타내는 가장 일반적인 방법입니다. 스키마를 통한 표준화는 보고가 정확하고 변형 가능성을 최소화하며 사용자 지정 쿼리 생성을 방지합니다. 잘못된 항목을 catch하는 자동화된 검사를 빌드합니다.

레이블을 수동으로 적용하거나 프로그래밍 방식으로 적용하거나 둘의 조합을 사용할 수 있습니다. 아키텍처 디자인 프로세스에는 스키마 디자인이 포함되어야 합니다. 기존 시스템을 사용하든 새 시스템을 빌드하든 레이블을 적용할 때 키/값 쌍에서 일관성을 유지합니다.

모든 데이터를 명확하게 분류할 수 있는 것은 아닙니다. 분류할 수 없는 데이터를 보고에 표시하는 방법에 대해 명시적으로 결정합니다.

실제 구현은 리소스 유형에 따라 달라집니다. 특정 Azure 리소스에는 기본 제공 분류 시스템이 있습니다. 예를 들어 Azure SQL Server에는 분류 엔진이 있고, 동적 마스킹을 지원하며, 메타데이터에 따라 보고서를 생성할 수 있습니다. Azure Service Bus 첨부된 메타데이터를 포함할 수 있는 메시지 스키마를 포함할 수 있습니다. 구현을 디자인할 때 플랫폼에서 지원하는 기능을 평가하고 활용합니다. 분류에 사용되는 메타데이터가 데이터 저장소와 별도로 격리되고 저장되어 있는지 확인합니다.

레이블을 자동으로 검색하고 적용할 수 있는 특수 분류 도구도 있습니다. 이러한 도구는 데이터 원본에 연결됩니다. Microsoft Purview에는 자동 검색 기능이 있습니다. 유사한 기능을 제공하는 타사 도구도 있습니다. 검색 프로세스는 수동 확인을 통해 유효성을 검사해야 합니다.

정기적으로 데이터 분류를 검토합니다. 분류 유지 관리는 작업에 기본 제공되어야 합니다. 그렇지 않으면 부실 메타데이터로 인해 식별된 목표 및 규정 준수 문제에 대한 잘못된 결과가 발생할 수 있습니다.

절충: 도구에 대한 비용 절충을 염두에 두어야 합니다. 분류 도구는 학습이 필요하며 복잡할 수 있습니다.

궁극적으로 분류는 중앙 팀을 통해 organization 롤업해야 합니다. 예상된 보고서 구조에 대한 입력을 가져옵니다. 또한 중앙 집중식 도구 및 프로세스를 활용하여 조직 조정을 수행하고 운영 비용을 완화합니다.

Azure 촉진

Microsoft Purview는 Azure Purview 및 Microsoft Purview 솔루션을 통합하여 organization 전체에서 데이터 자산에 대한 가시성을 제공합니다. 자세한 내용은 Microsoft Purview란?을 참조하세요.

Azure SQL Database, Azure SQL Managed Instance 및 Azure Synapse Analytics는 기본 제공 분류 기능을 제공합니다. 이러한 도구를 사용하여 데이터베이스의 중요한 데이터를 검색, 분류, 레이블 지정 및 보고할 수 있습니다. 자세한 내용은 데이터 검색 및 분류를 참조하세요.

예제

이 예제는 보안 기준(SE:01)에 설정된 IT(정보 기술) 환경을 기반으로 합니다. 아래 예제 다이어그램은 데이터가 분류되는 데이터 저장소를 보여줍니다.

1. 데이터베이스 및 디스크에 저장된 데이터는 관리자, 데이터베이스 관리자와 같은 소수의 사용자만 액세스할 수 있어야 합니다. 그런 다음 일반적인 사용자 또는 고객의 최종 클라이언트는 애플리케이션 또는 점프 상자와 같이 인터넷에 노출되는 계층에만 액세스할 수 있습니다.

2. 애플리케이션은 데이터베이스 또는 디스크에 저장된 데이터(예: 개체 스토리지 또는 파일 서버)와 통신합니다.

3. 경우에 따라 데이터가 온-프레미스 환경 및 퍼블릭 클라우드에 저장될 수 있습니다. 둘 다 일관되게 분류해야 합니다.

4. 운영자 사용 사례에서 원격 관리자는 클라우드 또는 워크로드를 실행하는 가상 머신의 액세스 점프 상자가 필요합니다. 데이터 분류 레이블에 따라 액세스 권한을 부여해야 합니다.

5. 데이터는 가상 머신을 통해 백 엔드 데이터베이스로 이동하고 데이터는 순회 지점 전체에서 동일한 수준의 기밀성으로 처리되어야 합니다.

6. 워크로드는 가상 머신 디스크에 직접 데이터를 저장합니다. 이러한 디스크는 분류를 위해 scope 있습니다.

7. 하이브리드 환경에서 다른 가상 사용자는 다양한 메커니즘을 통해 온-프레미스 워크로드에 액세스하여 다른 데이터 스토리지 기술 또는 데이터베이스에 연결할 수 있습니다. 분류 레이블에 따라 액세스 권한을 부여해야 합니다.

8. 온-프레미스 서버는 파일 서버, 개체 스토리지 및 관계형, no-SQL 및 데이터 웨어하우스와 같은 다양한 유형의 데이터베이스와 같이 분류 및 보호해야 하는 중요한 데이터에 연결합니다.

9. Microsoft Purview 규정 준수는 파일 및 이메일을 분류하는 솔루션을 제공합니다.

10. 클라우드용 Microsoft Defender 위의 사례에서 언급한 데이터를 저장하는 데 사용되는 많은 서비스를 포함하여 회사에서 사용자 환경의 규정 준수를 추적하는 데 도움이 되는 솔루션을 제공합니다.

관련 링크

• 데이터 분류 및 민감도 레이블 분류 - Microsoft Service Assurance
• 잘 설계된 데이터 분류 프레임워크 Create - Microsoft Service Assurance

다음 단계

전체 권장 사항 집합을 참조하세요.