클라우드 네이티브 앱을 위한 Azure 보안
팁
이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 eBook 에서 발췌한 것으로, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.
클라우드 네이티브 애플리케이션은 기존 애플리케이션보다 더 쉽고 보안은 더 까다로울 수 있습니다. 단점은 더 작은 애플리케이션을 보호하고 보안 인프라를 빌드하는 데 더 많은 에너지를 투자해야 한다는 것입니다. 대부분의 서비스 배포에서 프로그래밍 언어 및 스타일의 유형이 다른 특성은 다양한 공급자의 보안 게시판에 더 많은 주의를 기울여야 한다는 의미이기도 합니다.
반면에 각각 자체 데이터 저장소가 있는 소규모 서비스는 공격의 범위를 제한합니다. 공격자가 한 시스템을 손상시키면 공격자가 모놀리식 애플리케이션보다 다른 시스템으로 이동하는 것이 더 어려울 수 있습니다. 프로세스 경계는 강력한 경계입니다. 또한 데이터베이스 백업이 노출되면 해당 데이터베이스에 데이터의 하위 집합만 포함되고 개인 데이터가 포함될 가능성이 낮기 때문에 피해가 더 제한적입니다.
위협 모델링
장점이 클라우드 네이티브 애플리케이션의 단점을 능가하더라도 동일한 전체적인 보안 사고방식을 따라야 합니다. 보안 및 보안 사고는 개발 및 운영 스토리의 모든 단계에 포함되어야 합니다. 애플리케이션을 계획할 때 다음과 같은 질문을 합니다.
- 이 데이터가 손실되면 어떤 영향을 미치나요?
- 이 서비스에 잘못된 데이터 삽입으로 인한 피해를 어떻게 제한할 수 있나요?
- 누가 이 데이터에 액세스할 수 있어야 하나요?
- 개발 및 릴리스 프로세스에 대한 감사 정책이 있나요?
이러한 모든 질문은 위협 모델링이라는 프로세스의 일부입니다. 이 프로세스는 시스템에 어떤 위협이 있는지, 위협이 발생할 가능성 및 잠재적인 손상에 대한 질문에 답하려고 합니다.
위협 목록이 설정되면 완화할 가치가 있는지 여부를 결정해야 합니다. 경우에 따라 위협은 계획하기에 너무 가능성이 낮고 비용이 많이 들기 때문에 에너지를 소비할 가치가 없습니다. 예를 들어, 일부 상태 수준 작업자는 수백만 개의 디바이스에서 사용되는 프로세스 디자인에 변경 내용을 삽입할 수 있습니다. 이제 링 3에서 특정 코드를 실행하는 대신 해당 코드를 링 0에서 실행합니다. 이 프로세스는 하이퍼바이저를 우회하고 운영 체제 미설치 컴퓨터에서 공격 코드를 실행할 수 있는 익스플로잇을 허용하여 해당 하드웨어에서 실행 중인 모든 가상 머신에 대한 공격을 허용합니다.
변경된 프로세서는 해당 프로세서의 실리콘 설계에 대한 고급 지식과 현미경 없이는 감지하기 어렵습니다. 이 시나리오는 발생할 가능성이 낮고 완화하는 데 비용이 많이 들기 때문에 위협 모델에서는 이에 대한 익스플로잇 보호를 구축하는 것이 권장되지 않습니다.
Id 증분 공격(URL에서 Id=2를 Id=3으로 바꾸기) 또는 SQL 삽입을 허용하는 손상된 액세스 제어와 같은 더 가능성이 높은 위협은 보호를 구축하는 데 더 유리합니다. 회사의 명성을 구축하고 이를 훼손하는 당혹스러운 보안 허점을 방지하기 위해서는 이러한 위협을 완화해야 합니다.
최소 권한 원칙
컴퓨터 보안의 기본 아이디어 중 하나는 POLP(최소 권한 원칙)입니다. 이는 실제로 디지털 보안이든 실제 보안이든 대부분의 모든 형태의 보안에서 기본적인 아이디어입니다. 간단히 말해서, 원칙은 모든 사용자 또는 프로세스가 해당 작업을 실행할 수 있는 최소한의 권한을 가져야 한다는 것입니다.
예를 들어 은행 창구 직원이 금고에 액세스하는 것은 드문 일입니다. 그래서 일반 출납 직원은 금고를 직접 열 수 없습니다. 액세스 권한을 얻으려면 추가 보안 검사를 수행하는 은행 관리자를 통해 요청을 에스컬레이션해야 합니다.
컴퓨터 시스템에서 환상적인 예는 데이터베이스에 연결하는 사용자의 권한입니다. 대부분의 경우 데이터베이스 구조를 빌드하고 애플리케이션을 실행하는 데 사용되는 단일 사용자 계정이 있습니다. 극단적인 경우를 제외하고 애플리케이션을 실행하는 계정에는 스키마 정보를 업데이트할 수 있는 기능이 필요하지 않습니다. 서로 다른 수준의 권한을 제공하는 여러 계정이 있어야 합니다. 애플리케이션은 테이블의 데이터에 대한 읽기 및 쓰기 액세스 권한을 부여하는 권한 수준만 사용해야 합니다. 이러한 종류의 보호는 데이터베이스 테이블을 삭제하거나 악의적인 트리거를 도입하려는 공격을 제거합니다.
클라우드 네이티브 애플리케이션 빌드의 거의 모든 부분에서 최소 권한 원칙을 기억하면 도움이 될 수 있습니다. RBAC(역할 기반 액세스 제어)에서 방화벽, 네트워크 보안 그룹, 역할 및 범위를 설정할 때 해당 기능을 찾을 수 있습니다.
침투 테스트
애플리케이션이 더욱 복잡해짐에 따라 공격 벡터의 수는 놀라운 속도로 증가합니다. 위협 모델링은 시스템을 빌드하는 동일한 사용자가 실행하는 경향이 있다는 측면에서 결함이 있습니다. 많은 개발자가 사용자 상호 작용을 구상하고 사용할 수 없는 사용자 인터페이스를 빌드하는 데 어려움을 겪는 것과 마찬가지로 대부분의 개발자는 모든 공격 벡터를 파악하는 데 어려움을 겪습니다. 시스템을 빌드하는 개발자가 공격 방법론에 정통하지 않고 중요한 것을 놓칠 수도 있습니다.
침투 테스트 또는 "펜 테스트"에는 외부 행위자가 시스템을 공격하려고 시도하는 작업이 포함됩니다. 이러한 공격자는 외부 컨설팅 회사이거나 비즈니스의 다른 부분에서 우수한 보안 지식을 가진 다른 개발자일 수 있습니다. 그들은 시스템을 전복시키려 시도하기 위해 시스템 전권을 받았습니다. 그들은 패치가 필요한 광범위한 보안 허점을 발견하는 경우가 많이 있습니다. 경우에 따라 공격 벡터는 CEO에 대한 피싱 공격을 악용하는 것과 같이 전혀 예기치 못한 것일 수 있습니다.
Azure 자체는 Microsoft 내부의 해커 팀으로부터 지속적으로 공격을 받고 있습니다. 수년에 걸쳐 잠재적으로 치명적인 수십 가지 공격 벡터를 처음으로 찾아내어 외부에서 악용되기 전에 차단했습니다. 유혹하는 대상이 많을수록 작업자가 끊임없이 이를 악용할 가능성이 높아지고 Azure보다 더 유혹적인 대상이 세상에 몇 군데 있습니다.
모니터링
공격자가 애플리케이션에 침투하려고 시도하면 이에 대한 경고가 있어야 합니다. 종종 서비스의 로그를 검사하여 공격을 발견할 수 있습니다. 공격은 성공하기 전에 발견할 수 있는 명백한 징후를 남깁니다. 예를 들어, 암호 추측을 시도하는 공격자는 로그인 시스템에 많은 요청을 할 것입니다. 로그인 시스템 주변을 모니터링하면 일반적인 액세스 패턴과 일치하지 않는 이상한 패턴을 검색할 수 있습니다. 이 모니터링은 경고로 전환되어 운영 담당자에게 일종의 대응책을 활성화하도록 경고할 수 있습니다. 고도로 성숙한 모니터링 시스템은 이러한 편차를 기반으로 작업을 취하여 요청을 차단하거나 응답을 제한하는 규칙을 적극적으로 추가할 수도 있습니다.
빌드 보안
흔히 보안이 간과되는 곳 중 하나는 빌드 프로세스와 관련된 것입니다. 빌드는 안전하지 않은 코드 또는 체크인된 자격 증명 검사와 같은 보안 검사를 실행해야 할 뿐만 아니라 빌드 자체도 안전해야 합니다. 빌드 서버가 손상된 경우 임의의 코드를 제품에 도입하기 위한 환상적인 벡터를 제공합니다.
공격자가 웹 애플리케이션에 로그인하는 사람들의 암호를 훔치려 한다고 상상해 보세요. 다른 서버에 로그인 요청을 미러링하도록 체크 아웃된 코드를 수정하는 빌드 단계를 도입할 수 있습니다. 다음에 코드가 빌드를 거치면 자동으로 업데이트됩니다. 소스 코드 취약성 스캐닝은 빌드 전에 실행되기 때문에 이 취약성을 catch하지 못합니다. 마찬가지로 빌드 단계가 빌드 서버에 있기 때문에 아무도 코드 검토에서 이를 catch하지 못할 것입니다. 악용된 코드는 암호를 수집할 수 있는 프로덕션으로 이동합니다. 빌드 프로세스 변경 내용에 대한 감사 로그가 없거나 최소한 감사를 모니터링하는 사람이 없을 수 있습니다.
이 시나리오는 시스템에 침입하는 데 사용할 수 있는 가치가 낮아 보이는 대상의 완벽한 예입니다. 공격자가 시스템의 경계를 침범하면 원하는 곳 어디에서나 실제 피해를 줄 수 있는 수준으로 권한을 높이는 방법을 찾기 시작할 수 있습니다.
보안 코드 빌드
.NET Framework는 이미 매우 안전한 프레임워크입니다. 배열의 끝에서 벗어나는 것과 같은 비관리 코드의 일부 문제를 방지합니다. 보안 허점이 발견되면 이를 해결하기 위한 작업이 적극적으로 수행됩니다. 프레임워크에서 문제를 찾아 악용하는 대신 보고하도록 연구원에게 지불하는 버그 현상금 프로그램도 있습니다.
.NET 코드를 보다 안전하게 만드는 방법에는 여러 가지가 있습니다. .NET용 보안 코딩 지침 문서와 같은 지침에 따라 코드가 처음부터 안전하게 보호되도록 하기 위해 적절한 단계를 수행해야 합니다. OWASP top 10은 보안 코드를 빌드하기 위한 또 다른 유용한 가이드입니다.
빌드 프로세스는 프로덕션에 적용하기 전에 소스 코드에서 문제를 검색하기 위한 스캔 도구를 배치하기에 좋은 곳입니다. 대부분의 모든 프로젝트에는 다른 패키지에 대한 종속성이 있습니다. 오래된 패키지를 검사할 수 있는 도구는 야간 빌드에서 문제를 catch합니다. Docker 이미지를 빌드할 때도 기본 이미지에 알려진 취약성이 없는지 검사하고 확인하는 것이 유용합니다. 확인해야 할 또 다른 사항은 실수로 자격 증명을 체크인하지 않은 사람이 없는가 하는 점입니다.
기본 제공 보안
Azure는 대부분의 사용자를 위해 유용성과 보안의 균형을 유지하도록 설계되었습니다. 사용자마다 보안 요구 사항이 다르므로 클라우드 보안에 대한 방법을 미세 조정해야 합니다. Microsoft는 보안 센터에 많은 보안 정보를 게시합니다. 기본 제공 공격 완화 기술이 작동하는 방식을 이해하는 데 관심이 있는 전문가는 이 리소스를 가장 먼저 확인해야 합니다.
Azure Portal 내에서 Azure Advisor는 지속적으로 환경을 검사하고 권장 사항을 제시하는 시스템입니다. 이러한 권장 사항 중 일부는 사용자의 비용을 절약하기 위해 설계되었지만 다른 권장 사항은 Virtual Network로 보호되지 않고 전 세계에 공개된 스토리지 컨테이너와 같이 잠재적으로 안전하지 않은 구성을 식별하도록 설계되었습니다.
Azure 네트워크 인프라
온-프레미스 배포 환경에서는 네트워킹 설정에 많은 에너지가 사용됩니다. 라우터, 스위치 등을 설정하는 것은 복잡한 작업입니다. 네트워크는 특정 리소스가 다른 리소스와 통신하도록 허용하고 경우에 따라 액세스를 방지합니다. 자주 사용되는 네트워크 규칙은 절반만 개발된 코드가 잘못 실행되어 대량의 데이터를 삭제하는 경우 개발 환경에서 프로덕션 환경에 대한 액세스를 제한하는 것입니다.
기본적으로 대부분의 PaaS Azure 리소스에는 가장 기본적이고 허용 가능한 네트워킹 설정만 있습니다. 예를 들어 인터넷의 모든 사용자가 앱 서비스에 액세스할 수 있습니다. 새 SQL Server 인스턴스는 일반적으로 제한되어 외부 당사자가 액세스할 수 없지만 Azure 자체에서 사용하는 IP 주소 범위는 허용됩니다. 따라서 SQL 서버가 외부 위협으로부터 보호되는 동안 공격자는 Azure의 모든 SQL 인스턴스에 대한 공격을 시작할 수 있는 Azure 브리지헤드만 설정하면 됩니다.
다행히 대부분의 Azure 리소스는 세분화된 액세스 제어를 허용하는 Azure Virtual Network에 배치할 수 있습니다. 온-프레미스 네트워크가 더 넓은 세계로부터 보호되는 개인 네트워크를 설정하는 방식과 유사하게 가상 네트워크는 Azure 네트워크 내에 있는 개인 IP 주소의 섬입니다.
그림 9-1. Azure의 가상 네트워크.
온-프레미스 네트워크에 네트워크 액세스를 제어하는 방화벽이 있는 것과 같은 방식으로 가상 네트워크의 경계에 유사한 방화벽을 설정할 수 있습니다. 기본적으로 가상 네트워크의 모든 리소스는 여전히 인터넷과 통신할 수 있습니다. 어떤 형태의 명시적 방화벽 예외가 필요한 것은 들어오는 연결일 뿐입니다.
네트워크가 설정되면 스토리지 계정과 같은 내부 리소스가 Virtual Network에 있는 리소스의 액세스만 허용하도록 설정할 수 있습니다. 이 방화벽은 추가 보안 수준을 제공하므로 해당 스토리지 계정의 키가 유출될 경우 공격자가 유출된 키를 악용하기 위해 해당 스토리지 계정에 연결할 수 없습니다. 이 시나리오는 최소 권한 원칙의 또 다른 예입니다.
Azure Kubernetes 클러스터의 노드는 Azure 고유의 다른 리소스와 마찬가지로 가상 네트워크에 참여할 수 있습니다. 이 기능을 Azure Container Networking Interface라고 합니다. 실제로 가상 머신과 컨테이너 이미지가 할당되는 가상 네트워크 내에 서브넷을 할당합니다.
최소 권한의 원칙을 설명하는 경로를 계속 진행하면 Virtual Network 내의 모든 리소스가 다른 모든 리소스와 통신할 필요가 없습니다. 예를 들어 스토리지 계정 및 SQL 데이터베이스를 통해 웹 API를 제공하는 애플리케이션에서 데이터베이스와 스토리지 계정이 서로 통신해야 할 가능성은 거의 없습니다. 둘 사이의 모든 데이터 공유는 웹 애플리케이션을 통해 이루어집니다. 따라서 NSG(네트워크 보안 그룹)를 사용하여 두 서비스 간의 트래픽을 거부할 수 있습니다.
특히 트래픽 제한 없이 Azure를 사용하는 백그라운드에서 리소스 간의 통신을 거부하는 정책을 구현하기 성가실 수 있습니다. 일부 다른 클라우드에서는 네트워크 보안 그룹의 개념이 훨씬 더 널리 퍼져 있습니다. 예를 들어 AWS의 기본 정책은 NSG의 규칙에 의해 사용하도록 설정될 때까지 리소스가 서로 통신할 수 없다는 것입니다. 개발 속도는 느리지만 더 제한적인 환경은 더 안전한 기본값을 제공합니다. 적절한 DevOps 사례, 특히 Azure Resource Manager 또는 Terraform을 사용하여 권한을 관리하면 규칙을 더 쉽게 제어할 수 있습니다.
Virtual Network는 온-프레미스와 클라우드 리소스 간의 통신을 설정할 때도 유용할 수 있습니다. VPN(가상 사설망)을 사용하여 두 네트워크를 원활하게 연결할 수 있습니다. 이 방법을 사용하면 모든 사용자가 현장에 있는 시나리오에 대해 게이트웨이 없이 가상 네트워크를 실행할 수 있습니다. 이 네트워크를 설정하는 데 사용할 수 있는 여러 기술이 있습니다. 가장 간단한 방법은 여러 라우터와 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에는 작은 비밀 정보를 유지 관리하기 위한 유사한 서비스가 있습니다. 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 버전 내에서도 연결을 더 쉽게 해독할 수 있는 다양한 설정이 있습니다. 가장 좋은 작업은 서버 연결이 최신의 잘 구성된 프로토콜을 사용하고 있는지 확인하는 것입니다.
이 확인은 SSL 랩의 SSL 서버 테스트와 같은 외부 서비스에서 수행할 수 있습니다. 일반적인 Azure 엔드포인트(이 경우 서비스 버스 엔드포인트)에 대해 테스트를 실행하면 거의 만점에 가까운 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와 같은 도구는 변경 없이 계속 작동합니다. Always Encrypted는 아직 모든 SQL Server 드라이버에 모든 언어로 제공되지 않을 수 있습니다.
클라이언트별 키와 함께 사용할 수 있는 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만큼 안전한지 확인하는 데 사용할 수 있는 훌륭한 정적 분석 도구, 암호화 라이브러리 및 보안 사례가 많이 있습니다. 예로는 정적 분석 도구, 암호화 라이브러리 및 보안 사례가 있습니다.
.NET