클라우드 네이티브 앱에 대한 Azure 보안

클라우드 네이티브 애플리케이션은 기존 애플리케이션보다 더 쉽고 안전하기 어려울 수 있습니다. 단점으로, 더 작은 애플리케이션을 보호하고 보안 인프라를 구축하기 위해 더 많은 에너지를 헌납해야 합니다. 대부분의 서비스 배포에서 프로그래밍 언어 및 스타일의 이질적인 특성은 다양한 공급자의 보안 게시판에 더 많은 주의를 기울여야 한다는 것을 의미합니다.

반대로, 각각 자체 데이터 저장소가 있는 더 작은 서비스는 공격 범위를 제한합니다. 공격자가 한 시스템을 손상하는 경우 공격자가 모놀리식 애플리케이션보다 다른 시스템으로 이동하는 것이 더 어려울 수 있습니다. 프로세스 경계는 강력한 경계입니다. 또한 데이터베이스 백업이 노출되면 해당 데이터베이스에 데이터의 하위 집합만 포함되고 개인 데이터가 포함될 가능성이 낮기 때문에 손상이 더 제한됩니다.

위협 모델링

장점이 클라우드 네이티브 애플리케이션의 단점보다 크더라도 동일한 전체적인 보안 사고 방식을 따라야 합니다. 보안 및 보안 사고는 개발 및 운영 스토리의 모든 단계에 속해야 합니다. 애플리케이션을 계획할 때 다음과 같은 질문을 합니다.

• 이 데이터가 손실되는 영향은 무엇인가요?
• 이 서비스에 삽입되는 잘못된 데이터로 인한 손상을 어떻게 제한할 수 있나요?
• 누가 이 데이터에 액세스할 수 있어야 하나요?
• 개발 및 릴리스 프로세스와 관련된 감사 정책이 있나요?

이러한 모든 질문은 위협 모델링이라는 프로세스의 일부입니다. 이 프로세스는 시스템에 어떤 위협이 있는지, 위협이 얼마나 가능성이 있는지, 잠재적 손상에 대한 질문에 답하려고 합니다.

위협 목록이 설정되면 완화할 가치가 있는지 여부를 결정해야 합니다. 때로는 위협이 너무 가능성이 낮고 대비하는 데 비용이 많이 들어 에너지를 쓸 가치가 없는 경우도 있습니다. 예를 들어 일부 상태 수준 행위자가 수백만 개의 디바이스에서 사용되는 프로세스 디자인에 변경 내용을 삽입할 수 있습니다. 이제 링 3에서 특정 코드 조각을 실행하는 대신 해당 코드가 링 0에서 실행됩니다. 이 프로세스를 통해 하이퍼바이저를 우회하고 운영 체제 미설치 컴퓨터에서 공격 코드를 실행하여 해당 하드웨어에서 실행 중인 모든 가상 머신에 대한 공격을 허용할 수 있습니다.

변경된 프로세서는 현미경 및 해당 프로세서의 실리콘 설계에 대한 고급 지식 없이는 감지하기 어렵습니다. 이 시나리오는 발생할 가능성이 낮고 완화 비용이 많이 들기 때문에 아마도 어떤 위협 모델도 익스플로잇 보호 구축을 권장하지 않을 것입니다.

Id 액세스 제어가 깨져서 허용된 증분 공격(예를 들어 URL에서 Id=2을 Id=3로 대체) 또는 SQL 삽입과 같은 위협은 보호 조치를 마련하는 데 더 일반적입니다. 이러한 위협에 대한 완화는 회사의 명성을 훼손하는 당황스러운 보안 구멍을 구축하고 방지하는 데 매우 합리적입니다.

최소 권한 원칙

컴퓨터 보안의 창립 아이디어 중 하나는 POLP(최소 권한 원칙)입니다. 그것은 실제로 디지털 또는 물리적 보안의 대부분의 형태로 기본 아이디어입니다. 즉, 모든 사용자 또는 프로세스에 작업을 실행할 수 있는 최소 수의 권한이 있어야 한다는 원칙이 있습니다.

예를 들어 은행의 점원을 생각해 보십시오. 금고에 액세스하는 것은 드문 작업입니다. 따라서 평균 텔러는 금고를 직접 열 수 없습니다. 액세스 권한을 얻으려면 추가 보안 검사를 수행하는 은행 관리자를 통해 요청을 에스컬레이션해야 합니다.

컴퓨터 시스템에서 환상적인 예는 데이터베이스에 연결하는 사용자의 권한입니다. 대부분의 경우 데이터베이스 구조를 빌드하고 애플리케이션을 실행하는 데 사용되는 단일 사용자 계정이 있습니다. 극단적인 경우를 제외하고 애플리케이션을 실행하는 계정에는 스키마 정보를 업데이트할 수 있는 기능이 필요하지 않습니다. 다양한 수준의 권한을 제공하는 여러 계정이 있어야 합니다. 애플리케이션은 테이블의 데이터에 대한 읽기 및 쓰기 액세스 권한을 부여하는 권한 수준만 사용해야 합니다. 이러한 종류의 보호는 데이터베이스 테이블을 삭제하거나 악의적인 트리거를 도입하는 공격을 제거합니다.

클라우드 네이티브 애플리케이션을 빌드하는 거의 모든 부분에서 최소 권한 원칙을 기억하면 도움이 될 수 있습니다. RBAC(역할 기반 액세스 제어)에서 방화벽, 네트워크 보안 그룹, 역할 및 범위를 설정할 때 해당 기능을 찾을 수 있습니다.

침투 테스트

애플리케이션이 복잡해짐에 따라 공격 벡터 수가 놀라운 속도로 증가합니다. 위협 모델링은 시스템을 빌드하는 동일한 사용자가 실행하는 경향이 있다는 측면에서 결함이 있습니다. 많은 개발자가 사용자 상호 작용을 구상한 다음 사용할 수 없는 사용자 인터페이스를 빌드하는 데 어려움을 겪는 것과 마찬가지로 대부분의 개발자는 모든 공격 벡터를 보는 데 어려움을 겪습니다. 시스템을 빌드하는 개발자가 공격 방법론에 정통하지 않고 중요한 것을 놓칠 수도 있습니다.

침투 테스트 또는 "펜 테스트"에는 외부 행위자가 시스템을 공격하려고 시도하는 작업이 포함됩니다. 이러한 공격자는 외부 컨설팅 회사 또는 비즈니스의 다른 부분에서 좋은 보안 지식을 가진 다른 개발자일 수 있습니다. 그들은 시스템을 전복시키려고 시도할 수 있는 전권을 부여받습니다. 패치해야 하는 광범위한 보안 허점을 자주 발견할 수 있습니다. 때로는 공격 벡터가 CEO에 대한 피싱 공격을 악용하는 것과 같이 완전히 예상치 못한 일이 될 수 있습니다.

Azure 자체는 Microsoft 내의 해커 팀에서 지속적으로 공격을 받고 있습니다. 수년 동안 그들은 수십 개의 잠재적으로 치명적인 공격 벡터를 가장 먼저 찾아내었고, 외부에서 악용되기 전에 이를 차단했습니다. 대상을 더 유혹할수록 외부 행위자가 대상을 악용하려고 시도할 가능성이 높으며, Azure보다 더 유혹적인 대상은 전 세계에 거의 없습니다.

모니터링

공격자가 애플리케이션을 침투하려고 하면 경고가 표시되어야 합니다. 종종 서비스에서 로그를 검사하여 공격을 발견할 수 있습니다. 공격은 성공하기 전에 발견할 수 있는 명백한 징후를 남깁니다. 예를 들어 암호를 추측하려는 공격자는 로그인 시스템에 많은 요청을 합니다. 로그인 시스템을 모니터링하면 일반적인 액세스 패턴과 일치하지 않는 이상한 패턴을 감지할 수 있습니다. 이 모니터링은 작업 담당자에게 일종의 대책을 활성화하도록 경고할 수 있는 경고로 바뀔 수 있습니다. 고도로 완성도 높은 모니터링 시스템은 요청을 차단하거나 응답을 제한하는 규칙을 사전에 추가하는 이러한 편차에 따라 작업을 수행할 수도 있습니다.

빌드 보안

보안이 간과되는 한 곳은 빌드 프로세스입니다. 빌드는 안전하지 않은 코드 또는 체크 인 자격 증명 검색과 같은 보안 검사를 실행해야 할 뿐만 아니라 빌드 자체는 안전해야 합니다. 빌드 서버가 손상된 경우 제품에 임의 코드를 도입하기 위한 환상적인 벡터를 제공합니다.

공격자가 웹 애플리케이션에 로그인하는 사람들의 암호를 도용하려고 하는 경우를 상상해 보세요. 체크 아웃된 코드를 수정하여 로그인 요청을 다른 서버로 미러링하는 빌드 단계를 도입할 수 있습니다. 다음에 코드가 빌드를 통과하면 자동으로 업데이트됩니다. 소스 코드 취약성 검색은 빌드 전에 실행되므로 이 취약성을 발견하지 않습니다. 마찬가지로 빌드 단계가 빌드 서버에 있기 때문에 아무도 코드 검토에서 이를 발견하지 못합니다. 악용된 코드는 암호를 수집할 수 있는 프로덕션으로 이동합니다. 빌드 프로세스 변경에 대한 감사 로그가 없거나 감사를 모니터링하는 사람이 없을 수 있습니다.

이 시나리오는 시스템에 침입하는 데 사용할 수 있는 값이 낮아 보이는 대상의 완벽한 예입니다. 공격자가 시스템 경계를 위반하면 원하는 곳에서 실제 피해를 입힐 수 있는 지점까지 권한을 상승시키는 방법을 찾기 시작할 수 있습니다.

보안 코드 빌드

.NET Framework는 이미 매우 안전한 프레임워크입니다. 배열의 끝을 벗어나는 것과 같이 관리되지 않는 코드의 일부 문제를 방지합니다. 보안 허점이 발견되면 이를 해결하기 위한 작업이 적극적으로 수행됩니다. 프레임워크에서 문제를 찾아서 악용하는 대신 보고하도록 연구원에게 지불하는 버그 현상금 프로그램 도 있습니다.

.NET 코드를 보다 안전하게 만드는 방법에는 여러 가지가 있습니다. .NET 문서에 대한 보안 코딩 지침과 같은 지침을 따르는 것은 코드가 처음부터 안전하게 보호되도록 하기 위해 수행해야 하는 적절한 단계입니다. OWASP 상위 10개는 보안 코드를 빌드하기 위한 또 다른 귀중한 가이드입니다.

빌드 프로세스는 프로덕션으로 전환하기 전에 소스 코드에서 문제를 감지하기 위해 검사 도구를 배치하는 데 적합합니다. 대부분의 모든 프로젝트에는 다른 패키지에 대한 종속성이 있습니다. 오래된 패키지를 검색할 수 있는 도구는 야간 빌드에서 문제를 발견합니다. Docker 이미지를 빌드할 때도 기본 이미지에 알려진 취약성이 없는지 확인하고 확인하는 것이 유용합니다. 확인해야 할 또 다른 점은 아무도 실수로 자격 증명을 체크 인하지 않은 것입니다.

기본 제공 보안

Azure는 대부분의 사용자에 대한 유용성과 보안의 균형을 맞추도록 설계되었습니다. 사용자별로 보안 요구 사항이 다르므로 클라우드 보안에 대한 접근 방식을 세부적으로 조정해야 합니다. Microsoft는 보안 센터에 많은 보안 정보를 게시합니다. 이 리소스는 기본 제공 공격 완화 기술의 작동 방식을 이해하는 데 관심이 있는 전문가를 위한 첫 번째 중지가 되어야 합니다.

Azure Portal 내에서 Azure Advisor 는 지속적으로 환경을 검사하고 권장 사항을 만드는 시스템입니다. 이러한 권장 사항 중 일부는 사용자의 비용을 절감하도록 설계되었지만 다른 권장 사항은 스토리지 컨테이너가 전 세계에 열려 있고 Virtual Network로 보호되지 않는 등 잠재적으로 안전하지 않은 구성을 식별하도록 설계되었습니다.

Azure 네트워크 인프라

온-프레미스 배포 환경에서는 네트워킹을 설정하는 데 많은 에너지가 필요합니다. 라우터, 스위치 등을 설정하는 작업은 복잡합니다. 네트워크에서는 특정 리소스가 다른 리소스와 통신하고 경우에 따라 액세스를 방지할 수 있습니다. 빈번한 네트워크 규칙 중 하나는 예상치 못한 상황에서 반쯤 개발된 코드 조각이 잘못 실행되어 상당한 양의 데이터를 삭제할 수 있다는 우려로 개발 환경에서 프로덕션 환경에 대한 액세스를 제한하는 것입니다.

기본적으로 대부분의 PaaS Azure 리소스에는 가장 기본적이고 허용적인 네트워킹 설정만 있습니다. 예를 들어 인터넷의 모든 사용자는 앱 서비스에 액세스할 수 있습니다. 일반적으로 새 SQL Server 인스턴스는 외부 당사자가 액세스할 수 없도록 제한되지만 Azure 자체에서 사용하는 IP 주소 범위는 허용됩니다. 따라서 SQL Server는 외부 위협으로부터 보호되지만 공격자는 Azure의 모든 SQL 인스턴스에 대한 공격을 시작할 수 있는 Azure 브리지헤드만 설정하면 됩니다.

다행히 대부분의 Azure 리소스는 세분화된 액세스 제어를 허용하는 Azure Virtual Network에 배치할 수 있습니다. 온-프레미스 네트워크가 더 넓은 세계에서 보호되는 프라이빗 네트워크를 설정하는 방식과 마찬가지로 가상 네트워크는 Azure 네트워크 내에 있는 개인 IP 주소의 섬입니다.

그림 9-1. Azure의 가상 네트워크입니다.

온-프레미스 네트워크에 네트워크에 대한 액세스를 제어하는 방화벽이 있는 것과 동일한 방식으로 가상 네트워크 경계에 유사한 방화벽을 설정할 수 있습니다. 기본적으로 가상 네트워크의 모든 리소스는 여전히 인터넷과 통신할 수 있습니다. 어떤 형태의 명시적 방화벽 예외가 필요한 들어오는 연결일 뿐입니다.

네트워크를 설정하면 스토리지 계정과 같은 내부 리소스를 가상 네트워크에 있는 리소스에 의한 액세스만 허용하도록 설정할 수 있습니다. 이 방화벽은 해당 스토리지 계정의 키가 유출될 경우 공격자가 해당 계정에 연결하여 유출된 키를 악용할 수 없는 추가 수준의 보안을 제공합니다. 이 시나리오는 최소 권한 원칙의 또 다른 예입니다.

Azure Kubernetes 클러스터의 노드는 Azure에 더 네이티브인 다른 리소스와 마찬가지로 가상 네트워크에 참여할 수 있습니다. 이 기능을 Azure Container Networking Interface라고 합니다. 실제로 가상 머신 및 컨테이너 이미지가 할당되는 가상 네트워크 내에 서브넷을 할당합니다.

Virtual Network 내의 모든 리소스가 다른 모든 리소스와 통신할 필요가 없는 최소 권한의 원칙을 설명하는 경로를 계속 진행합니다. 예를 들어 스토리지 계정 및 SQL 데이터베이스를 통해 웹 API를 제공하는 애플리케이션에서는 데이터베이스와 스토리지 계정이 서로 통신해야 할 가능성이 낮습니다. 데이터 공유는 웹 애플리케이션을 통해 진행합니다. 따라서 NSG(네트워크 보안 그룹) 를 사용하여 두 서비스 간의 트래픽을 거부할 수 있습니다.

리소스 간 통신을 거부하는 정책은 특히 트래픽 제한 없이 Azure를 사용하는 배경에서 구현하는 것이 불편할 수 있습니다. 다른 클라우드에서는 네트워크 보안 그룹의 개념이 훨씬 더 널리 퍼져 있습니다. 예를 들어 AWS의 기본 정책은 NSG의 규칙에 의해 활성화될 때까지 리소스가 서로 통신할 수 없다는 것입니다. 개발 속도가 느리지만 더 제한적인 환경은 보다 안전한 기본값을 제공합니다. 적절한 DevOps 사례를 사용하는 경우, 특히 Azure Resource Manager 또는 Terraform 을 사용하여 사용 권한을 관리하면 규칙을 더 쉽게 제어할 수 있습니다.

가상 네트워크는 온-프레미스와 클라우드 리소스 간의 통신을 설정할 때도 유용할 수 있습니다. 가상 사설망을 사용하여 두 네트워크를 원활하게 연결할 수 있습니다. 이 방법을 사용하면 모든 사용자가 현장에 있는 시나리오에 대해 어떤 종류의 게이트웨이도 없이 가상 네트워크를 실행할 수 있습니다. 이 네트워크를 설정하는 데 사용할 수 있는 다양한 기술이 있습니다. 가장 간단한 방법은 여러 라우터와 Azure 간에 설정할 수 있는 사이트 간 VPN 을 사용하는 것입니다. 트래픽은 다른 트래픽과 바이트당 동일한 비용으로 인터넷을 통해 암호화되고 터널됩니다. 더 많은 대역폭 또는 더 많은 보안이 바람직한 시나리오의 경우 Azure는 온-프레미스 네트워크와 Azure 간에 프라이빗 회로를 사용하는 Express Route 라는 서비스를 제공합니다. 설정하는 것이 더 비용이 많이 들고 어렵지만 보안도 더 안전합니다.

Azure 리소스에 대한 액세스를 제한하기 위한 역할 기반 액세스 제어

RBAC는 Azure에서 실행되는 애플리케이션에 ID를 제공하는 시스템입니다. 애플리케이션은 키 또는 암호를 사용하는 대신 또는 이 ID를 사용하여 리소스에 액세스할 수 있습니다.

보안 주체

RBAC의 첫 번째 구성 요소는 보안 주체입니다. 보안 주체는 사용자, 그룹, 서비스 주체 또는 관리 ID일 수 있습니다.

그림 9-2. 보안 주체 유형이 다릅니다.

• 사용자 - Azure Active Directory에 계정이 있는 모든 사용자가 사용자입니다.
• 그룹 - Azure Active Directory의 사용자 컬렉션입니다. 그룹의 구성원으로서 사용자는 자신의 역할 외에도 해당 그룹의 역할을 맡습니다.
• 서비스 주체 - 서비스 또는 애플리케이션이 실행되는 보안 ID입니다.
• 관리 ID - Azure에서 관리하는 Azure Active Directory ID입니다. 관리 ID는 일반적으로 Azure 서비스에 인증하기 위한 자격 증명을 관리하는 클라우드 애플리케이션을 개발할 때 사용됩니다.

보안 주체는 대부분의 리소스에 적용할 수 있습니다. 이 측면은 Azure Kubernetes 내에서 실행되는 컨테이너에 보안 주체를 할당하여 Key Vault에 저장된 비밀에 액세스할 수 있음을 의미합니다. Azure Function은 Active Directory 인스턴스와 통신하여 호출 사용자에 대한 JWT의 유효성을 검사할 수 있는 권한을 사용할 수 있습니다. 서비스 주체를 사용하여 서비스를 사용하도록 설정하면 역할 및 범위를 사용하여 해당 권한을 세분화하여 관리할 수 있습니다.

역할

보안 주체는 여러 역할을 수행할 수 있으며, 복식 비유를 사용하여 여러 모자를 쓸 수 있습니다. 각 역할은 "Azure Service Bus 엔드포인트에서 메시지 읽기"와 같은 일련의 권한을 정의합니다. 보안 주체의 유효 권한 집합은 보안 주체가 가진 모든 역할에 할당된 모든 권한의 조합입니다. Azure에는 많은 수의 기본 제공 역할이 있으며 사용자는 자신의 역할을 정의할 수 있습니다.

그림 9-3. RBAC 역할 정의.

Azure에는 소유자, 기여자, 읽기 권한자 및 사용자 계정 관리자와 같은 다양한 상위 수준 역할도 기본 제공됩니다. 소유자 역할을 사용하면 보안 주체가 모든 리소스에 액세스하고 다른 사용자에게 권한을 할당할 수 있습니다. 기여자는 모든 리소스에 대해 동일한 수준의 액세스 권한을 가지지만 권한을 할당할 수는 없습니다. 판독기는 기존 Azure 리소스만 볼 수 있으며 사용자 계정 관리자는 Azure 리소스에 대한 액세스를 관리할 수 있습니다.

DNS 영역 기여자 같은 보다 세분화된 기본 제공 역할은 단일 서비스로 제한됩니다. 보안 주체는 다양한 역할을 수행할 수 있습니다.

범위

역할은 Azure 내의 제한된 리소스 집합에 적용할 수 있습니다. 예를 들어 Service Bus 큐에서 읽기의 이전 예제에 범위를 적용하면 사용 권한을 단일 큐로 좁힐 수 있습니다. "Azure Service Bus 엔드포인트 blah.servicebus.windows.net/queue1에서 메시지 읽기"

범위는 단일 리소스만큼 좁거나 전체 리소스 그룹, 구독 또는 관리 그룹에 적용할 수 있습니다.

보안 주체에 특정 권한이 있는지 테스트할 때 역할과 범위의 조합이 고려됩니다. 이 조합은 강력한 권한 부여 메커니즘을 제공합니다.

거절하다

이전에는 RBAC에 대해 "허용" 규칙만 적용되었습니다. 이 동작으로 인해 일부 범위를 빌드하기가 복잡해졌습니다. 예를 들어 스토리지 계정의 무한 목록에 명시적 권한을 부여하는 데 필요한 권한을 제외한 모든 스토리지 계정에 대한 보안 주체 액세스를 허용합니다. 새 스토리지 계정을 만들 때마다 이 계정 목록에 추가해야 합니다. 이로 인해 확실히 바람직하지 않은 관리 오버헤드가 추가되었습니다.

거부 규칙은 허용 규칙보다 우선합니다. 이제 동일한 "하나만 허용" 범위를 나타내는 두 개의 규칙 "모두 허용" 및 "이 하나의 특정 항목 거부"로 표시될 수 있습니다. 규칙을 거부하면 관리가 용이할 뿐만 아니라 모든 사용자에 대한 액세스를 거부하여 더 안전한 리소스를 허용합니다.

액세스 확인

상상할 수 있듯이 역할과 범위가 많으면 서비스 주체의 효과적인 사용 권한을 파악하기가 매우 어려울 수 있습니다. 그 위에 거부 규칙을 추가하는 것은 단지 복잡성을 증가시킬 뿐입니다. 다행히 모든 서비스 주체에 대한 유효 권한을 표시할 수 있는 권한 계산기가 있습니다. 일반적으로 그림 9-3과 같이 포털의 IAM 탭 아래에 있습니다.

그림 9-4. 앱 서비스에 대한 권한 계산기입니다.

비밀 보호

암호 및 인증서는 공격자의 일반적인 공격 벡터입니다. 암호 해독 하드웨어는 무차별 암호 대입 공격을 수행하고 초당 수십억 개의 암호를 추측하려고 할 수 있습니다. 따라서 다양한 문자를 사용하여 리소스에 액세스하는 데 사용되는 암호가 강력해야 합니다. 이러한 암호는 기억하기 거의 불가능한 암호의 종류입니다. 다행히 Azure의 암호는 실제로 사람이 알 필요가 없습니다.

많은 보안 전문가들은 암호 관리자를 사용하여 자신의 암호를 유지하는 것이 가장 좋은 방법이라고 제안합니다. 한 위치에서 암호를 중앙 집중화하지만 매우 복잡한 암호를 사용하고 각 계정에 대해 고유한지 확인할 수도 있습니다. 동일한 시스템이 Azure 내에 존재합니다. 비밀에 대한 중앙 저장소입니다.

Azure Key Vault (애저 키 볼트)

Azure Key Vault는 데이터베이스, API 키 및 인증서와 같은 항목에 대한 암호를 저장하는 중앙 집중식 위치를 제공합니다. 비밀이 금고에 입력되면 다시는 표시되지 않으며, 해당 비밀을 추출하거나 보기 위한 명령은 의도적으로 복잡하게 되어 있습니다. 안전한 정보는 소프트웨어 암호화 또는 FIPS 140-2 수준 2 유효성이 검사된 하드웨어 보안 모듈을 사용하여 보호됩니다.

키 자격 증명 모음에 대한 액세스는 RBAC를 통해 제공되므로 모든 사용자가 자격 증명 모음에 있는 정보에 접근할 수 있는 것은 아닙니다. 웹 애플리케이션이 Azure Key Vault에 저장된 데이터베이스 연결 문자열에 액세스하려고 하는 경우를 가정해 보겠습니다. 액세스 권한을 얻으려면 애플리케이션이 서비스 주체를 사용하여 실행해야 합니다. 이 맡은 역할에서 금고에서 비밀을 읽을 수 있습니다. 애플리케이션이 자격 증명 모음에 대한 액세스를 추가로 제한할 수 있는 다양한 보안 설정이 있으므로 비밀을 업데이트할 수는 없지만 읽기만 가능합니다.

키 볼트에 대한 접근을 모니터링하여 예상된 응용 프로그램만이 볼트에 접근하는지 확인할 수 있습니다. 로그를 Azure Monitor에 다시 통합하여 예기치 않은 조건이 발생할 때 경고를 설정하는 기능을 잠금 해제할 수 있습니다.

쿠버네티스

Kubernetes 내에는 작은 비밀 정보를 유지 관리하는 유사한 서비스가 있습니다. Kubernetes 비밀은 일반적인 kubectl 실행 파일을 통해 설정할 수 있습니다.

비밀을 만드는 것은 저장할 값의 base64 버전을 찾는 것만큼 간단합니다.

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

그런 다음, 아래 예시와 유사한 형식으로 secret.yml라는 비밀 파일에 추가합니다.

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

마지막으로 다음 명령을 실행하여 이 파일을 Kubernetes에 로드할 수 있습니다.

kubectl apply -f ./secret.yaml

그런 다음 이러한 비밀을 볼륨에 탑재하거나 환경 변수를 통해 컨테이너 프로세스에 노출할 수 있습니다. 애플리케이션을 빌드하는 12단계 앱 접근 방식은 가장 낮은 공통 분모를 사용하여 설정을 애플리케이션으로 전송하는 것을 제안합니다. 환경 변수는 운영 체제 또는 애플리케이션에 관계없이 지원되므로 가장 낮은 공통 분모입니다.

기본 제공 Kubernetes 비밀을 사용하는 대안은 Kubernetes 내에서 Azure Key Vault의 비밀에 액세스하는 것입니다. 이 작업을 수행하는 가장 간단한 방법은 비밀을 로드하려는 컨테이너에 RBAC 역할을 할당하는 것입니다. 그런 다음, 애플리케이션은 Azure Key Vault API를 사용하여 비밀에 액세스할 수 있습니다. 그러나 이 방법은 코드를 수정해야 하며 환경 변수 사용 패턴을 따르지 않습니다. 대신 컨테이너에 값을 삽입할 수 있습니다. 이 방법은 클러스터의 사용자가 액세스할 수 있으므로 Kubernetes 비밀을 직접 사용하는 것보다 실제로 더 안전합니다.

전송 중 및 보관 중 암호화

데이터를 안전하게 유지하는 것은 디스크에 있든 다양한 서비스 간에 전송하든 간에 중요합니다. 데이터가 누출되지 않도록 하는 가장 효과적인 방법은 다른 사용자가 쉽게 읽을 수 없는 형식으로 암호화하는 것입니다. Azure는 다양한 암호화 옵션을 지원합니다.

운송 중

Azure에서 네트워크의 트래픽을 암호화하는 방법에는 여러 가지가 있습니다. Azure 서비스에 대한 액세스는 일반적으로 TLS(전송 계층 보안)를 사용하는 연결을 통해 수행됩니다. 예를 들어 Azure API에 대한 모든 연결에는 TLS 연결이 필요합니다. 마찬가지로 Azure Storage의 엔드포인트에 대한 연결은 TLS 암호화 연결을 통해서만 작동하도록 제한할 수 있습니다.

TLS는 복잡한 프로토콜이며 연결이 TLS를 사용하고 있다는 것을 아는 것만으로는 보안을 보장하기에 충분하지 않습니다. 예를 들어 TLS 1.0은 만성적으로 안전하지 않으며 TLS 1.1은 그다지 좋지 않습니다. TLS 버전 내에서도 연결을 쉽게 해독할 수 있는 다양한 설정이 있습니다. 가장 좋은 작업은 서버 연결이 up-to-date 및 잘 구성된 프로토콜을 사용하고 있는지 확인하고 확인하는 것입니다.

이 검사는 SSL 랩의 SSL 서버 테스트와 같은 외부 서비스에서 수행할 수 있습니다. 일반적인 Azure 엔드포인트에 대한 테스트 실행(이 경우 Service Bus 엔드포인트)은 거의 완벽한 A 점수를 생성합니다.

Azure SQL 데이터베이스와 같은 서비스도 TLS 암호화를 사용하여 데이터를 숨깁니다. TLS를 사용하여 전송 중인 데이터를 암호화하는 방법에 대한 흥미로운 부분은 Microsoft에서도 TLS를 실행하는 컴퓨터 간의 연결에서 수신 대기할 수 없다는 것입니다. 데이터가 Microsoft 자체 또는 표준 공격자보다 더 많은 리소스를 가진 국가 행위자로부터 위험에 처할 수 있다고 우려하는 회사에는 이로 인해 안심이 될 것입니다.

그림 9-5. Service Bus 엔드포인트에 대한 A 점수를 보여 주는 SSL 랩 보고서입니다.

이 수준의 암호화는 항상 충분하지는 않지만 Azure TLS 연결이 매우 안전하다는 확신을 심어주어야 합니다. Azure는 암호화가 개선됨에 따라 보안 표준을 계속 발전시킬 것입니다. 보안 표준을 보고 Azure를 업데이트하는 사람이 있다는 것을 아는 것은 좋은 일입니다.

휴식 중

모든 애플리케이션에는 데이터가 디스크에 있는 여러 위치가 있습니다. 애플리케이션 코드 자체는 일부 스토리지 메커니즘에서 로드됩니다. 또한 대부분의 애플리케이션은 SQL Server, Cosmos DB 또는 가격 효율적인 Table Storage와 같은 일종의 데이터베이스를 사용합니다. 이러한 데이터베이스는 모두 암호화된 스토리지를 사용하여 적절한 권한이 있는 애플리케이션 이외의 다른 사용자가 데이터를 읽을 수 없도록 합니다. 시스템 운영자도 암호화된 데이터를 읽을 수 없습니다. 따라서 고객은 비밀 정보가 비밀로 유지되도록 확신할 수 있습니다.

스토리지

Azure의 많은 부분을 뒷받침하는 것은 Azure Storage 엔진입니다. 가상 머신 디스크는 Azure Storage 위에 탑재됩니다. Azure Kubernetes Service는 Azure Storage에서 호스트되는 가상 머신에서 실행됩니다. Azure Functions Apps 및 Azure Container Instances와 같은 서버리스 기술도 Azure Storage의 일부인 디스크가 부족합니다.

Azure Storage가 잘 암호화된 경우 대부분의 다른 모든 항목도 암호화할 수 있는 기반을 제공합니다. Azure Storage 는FIPS 140-2 호환 256비트 AES로 암호화됩니다. 이것은 지난 20 년 동안 광범위한 학술 조사의 대상이된 잘 알려진 암호화 기술입니다. 현재 키에 대한 지식이 없는 사람이 AES로 암호화된 데이터를 읽을 수 있는 알려진 실제 공격은 없습니다.

기본적으로 Azure Storage를 암호화하는 데 사용되는 키는 Microsoft에서 관리합니다. 이러한 키에 대한 악의적인 액세스를 방지하기 위한 광범위한 보호가 마련되어 있습니다. 그러나 특정 암호화 요구 사항이 있는 사용자는 Azure Key Vault에서 관리되는 자체 스토리지 키를 제공할 수도 있습니다. 이러한 키는 언제든지 해지할 수 있으며, 이렇게 하면 스토리지 계정의 콘텐츠에 접근할 수 없게 됩니다.

가상 머신은 암호화된 스토리지를 사용하지만 Windows의 BitLocker 또는 Linux의 DM-Crypt 같은 기술을 사용하여 다른 암호화 계층을 제공할 수 있습니다. 이러한 기술은 디스크 이미지가 스토리지에서 유출되더라도 읽기가 거의 불가능합니다.

Azure SQL

Azure SQL에서 호스트되는 데이터베이스는 TDE(투명한 데이터 암호화) 라는 기술을 사용하여 데이터가 암호화된 상태로 유지되도록 합니다. 새로 만든 모든 SQL 데이터베이스에서 기본적으로 사용하도록 설정되지만 레거시 데이터베이스에 대해 수동으로 사용하도록 설정해야 합니다. TDE는 데이터베이스뿐만 아니라 백업 및 트랜잭션 로그의 실시간 암호화 및 암호 해독도 실행합니다.

암호화 매개 변수는 데이터베이스에 master 저장되고 시작 시 나머지 작업에 대한 메모리로 읽혀집니다. 즉, 데이터베이스는 master 암호화되지 않은 상태로 유지되어야 합니다. 실제 키는 Microsoft에서 관리합니다. 그러나 정확한 보안 요구 사항을 가진 사용자는 Azure Storage에 대해 수행되는 것과 거의 동일한 방식으로 Key Vault에 자체 키를 제공할 수 있습니다. Key Vault는 키 회전 및 해지와 같은 서비스를 제공합니다.

TDS의 "투명" 부분은 암호화된 데이터베이스를 사용하는 데 필요한 클라이언트 변경 내용이 없다는 사실에서 비롯됩니다. 이 방법을 사용하면 보안이 양호하지만 사용자가 데이터를 해독할 수 있도록 데이터베이스 암호를 누수하는 것으로 충분합니다. 데이터베이스의 개별 열 또는 테이블을 암호화하는 또 다른 방법이 있습니다. Always Encrypted 는 암호화된 데이터가 데이터베이스 내부의 일반 텍스트로 표시되지 않도록 합니다.

이 암호화 계층을 설정하려면 SQL Server Management Studio의 마법사를 통해 실행하여 암호화의 종류와 Key Vault에서 연결된 키를 저장할 위치를 선택해야 합니다.

그림 9-6. Always Encrypted를 사용하여 암호화할 테이블의 열 선택

이러한 암호화된 열에서 정보를 읽는 클라이언트 애플리케이션은 암호화된 데이터를 읽기 위해 특별히 허용해야 합니다. 연결 문자열은 Column Encryption Setting=Enabled로 업데이트되어야 하며, 클라이언트 자격 증명은 Key Vault에서 검색해야 합니다. 그런 다음 SQL Server 클라이언트를 열 암호화 키로 준비해야 합니다. 이 작업이 완료되면 나머지 작업은 SQL 클라이언트에 표준 인터페이스를 사용합니다. 즉, SQL 클라이언트를 기반으로 빌드된 Dapper 및 Entity Framework와 같은 도구는 변경 없이 계속 작동합니다. 모든 언어의 모든 SQL Server 드라이버에 대해 Always Encrypted를 아직 사용할 수 없습니다.

TDE와 Always Encrypted의 조합은 둘 다 클라이언트별 키와 함께 사용할 수 있으므로 가장 정확한 암호화 요구 사항도 지원됩니다.

Cosmos DB (코스모스 데이터베이스)

Cosmos DB는 Azure에서 Microsoft에서 제공하는 최신 데이터베이스입니다. 처음부터 보안 및 암호화를 염두에 두고 구축되었습니다. AES-256비트 암호화는 모든 Cosmos DB 데이터베이스에 대한 표준이며 사용하지 않도록 설정할 수 없습니다. 통신을 위한 TLS 1.2 요구 사항과 함께 전체 스토리지 솔루션이 암호화됩니다.

그림 9-7. Cosmos DB 내의 데이터 암호화 흐름입니다.

Cosmos DB는 고객 암호화 키를 제공하지 않지만, 팀이 고객 암호화 키 없이도 PCI-DSS 준수하도록 상당한 노력을 기울였습니다. 또한 Cosmos DB는 아직 Azure SQL의 Always Encrypted와 유사한 단일 열 암호화를 지원하지 않습니다.

보안 유지

Azure에는 매우 안전한 제품을 릴리스하는 데 필요한 모든 도구가 있습니다. 그러나 체인은 가장 약한 링크만큼 강력합니다. Azure 위에 배포된 애플리케이션이 적절한 보안 사고방식과 좋은 보안 감사로 개발되지 않은 경우 체인의 약한 고리가 됩니다. Azure에 설치된 소프트웨어가 Azure 자체만큼 안전한지 확인하는 데 사용할 수 있는 많은 훌륭한 정적 분석 도구, 암호화 라이브러리 및 보안 사례가 있습니다. 예를 들어 정적 분석 도구 및 암호화 라이브러리가 있습니다.