시나리오 2 솔루션 - 중요 업무용 애플리케이션

완료됨

이전 단원에서는 119 긴급 출동 시스템의 고가용성과 관련된 시나리오를 살펴보았습니다. 이 단원에서는 하나의 잠재적 솔루션과 고려해야 할 몇 가지 다른 항목을 검토해 보겠습니다.

검토할 때는 제공된 솔루션을 이전 단원에서 개발한 솔루션과 비교해야 합니다. 문제에 적합한 솔루션은 두 개 이상인 경우가 많으며 각 솔루션에는 항상 장단점이 있습니다. 개발한 솔루션에서 제안된 솔루션과 다른 항목은 무엇입니까? 개발한 솔루션에 재고해 볼 수 있는 항목이 있나요? 제공된 솔루션의 항목 중 개발한 솔루션에서 더 확실하게 처리된다고 생각하는 항목이 있나요?

배포 옵션 및 구성

시나리오 해결의 첫 번째 선택 사항은 가장 적합한 Azure SQL 배포 옵션을 파악하는 것인 경우가 많습니다. SLA(서비스 수준 계약)만 고려하는 경우에는 Azure SQL Database만 제공할 수 있는 99.995% SLA를 요구합니다. 이 수준의 SLA를 달성하려면 중요 비즈니스용 서비스 계층을 배포하고 가용성 영역을 사용하도록 설정해야 합니다.

또 다른 의사 결정 사항은 재해 시 지역 중복을 사용하도록 설정하고 고가용성을 유지 관리하는 방법과 관련이 있습니다. 여기서는 지역에서 복제 및 자동 장애 조치 그룹 둘 다 옵션이 되지만 자동 장애 조치 그룹을 사용하면 필요한 경우 고객이 연결 문자열을 변경하지 않고도 장애 조치할 수 있습니다. 이 설정은 애플리케이션 연결 문자열을 업데이트하는 가동 중지 시간을 줄이는 데 도움이 될 수 있습니다. 업데이트가 필요하지 않기 때문입니다. 모니터링 쿼리를 구성하여 상태를 확인할 수도 있습니다. 이렇게 하면 문제가 발생하는 경우 장애 조치를 강제 적용할 수 있습니다.

이 구성에서는 공동 배치의 역할에 대해 생각해 보는 것도 중요합니다. 고가용성을 유지 관리하려면 애플리케이션은 가능한 한 데이터베이스와 가까이 있어야 하므로 반드시 동일한 지역에 있게 됩니다. 고객은 애플리케이션이 자동 장애 조치 그룹의 지역 둘 다에 배포되기를 원하므로 애플리케이션의 중복 복사본(예: 웹앱)이 존재하게 됩니다. 장애 조치가 있는 경우 Azure Traffic Manager를 사용하여 보조 지역의 애플리케이션으로 트래픽 경로를 바꿀 수 있습니다.

DBA 및 중요한 데이터

911 긴급 출동 시스템 코디네이터는 중요한 데이터(예: 건강 기록 및 기타 개인 정보)를 보호하는 동시에 DBA가 작업을 수행하도록 허용하는 것에 대해 우려를 표시했습니다.

DBA가 특정 열에 저장된 중요한 데이터를 볼 수 없도록 하고 중요한 데이터가 있는 테이블에 대한 모든 액세스가 모니터링되도록 하는 데 몇 가지 Azure SQL 기술을 사용할 수 있습니다. SQL 감사를 사용하여 액세스를 모니터링하는 것이 좋지만, DBA가 여전히 데이터를 볼 수 있습니다. 데이터 분류를 사용하여 중요한 데이터를 분류하면 중요한 데이터에 레이블이 지정되고 SQL 감사를 사용하여 추적할 수 있으므로 도움이 됩니다. 하지만 DBA가 여전히 중요한 데이터를 볼 수 있습니다. 동적 데이터 마스킹을 사용하면 중요한 데이터를 마스킹하는 데 도움이 될 수 있지만 사용 권한만 있는 db_owner가 사용자 데이터를 볼 수 없게 할 수 없습니다.

데이터베이스에 매우 중요한 데이터가 있는 경우 Always Encrypted를 사용하여 안전하게 db_owner가 해당 데이터를 볼 수 없게 할 수 있습니다. 역할 구분을 통해 Always Encrypted 키를 관리하여 보안 관리자는 데이터베이스에 액세스할 수 없도록 하고 DBA는 일반 텍스트로 된 물리적 키에 액세스할 수 없도록 할 수도 있습니다. 이러한 전략을 SQL 감사를 통한 모니터링과 함께 활용하면 DBA에게 db_owner 권한이 있어도 중요한 데이터에 대한 액세스를 모니터링하고, 마스킹하고, 추적할 수 있습니다.

DBA는 중요한 데이터를 마스킹해야 하지만 Azure Portal, SQL Server Management Studio 또는 Azure Data Studio를 사용하여 성능 문제를 해결할 수도 있어야 합니다. 그리고 Microsoft Entra 주체에 매핑되어야 하는 새로운 포함된 데이터베이스 사용자를 만들 수 있어야 합니다.

한 가지 솔루션은 각 인스턴스의 DBA를 위해 SQL DBA라는 Microsoft Entra 그룹을 만드는 것입니다. 그런 다음, 해당 그룹에 Azure RBAC(역할 기반 액세스 제어) 역할인 SQL Server Contributor 역할을 할당합니다. 마지막으로 그룹을 논리 서버의 Microsoft Entra 관리자로 설정할 수 있습니다.