플랫폼 코드 무결성
Microsoft Azure 같은 복잡한 시스템을 운영할 때 나타나는 중대한 문제는 권한 있는 소프트웨어만 시스템에서 실행되도록 하는 것입니다. 권한이 없는 소프트웨어는 모든 비즈니스에 다음과 같은 몇 가지 위험을 초래합니다.
- 알려진 취약성이 있는 전용 공격 도구, 사용자 지정 맬웨어 및 타사 소프트웨어와 같은 보안 위험
- 승인된 변경 관리 프로세스가 새 소프트웨어를 도입할 때 사용되지 않는 경우의 규정 준수 위험
- 외부에서 개발된 소프트웨어의 품질 위험: 비즈니스 운영 요구 사항을 충족하지 못할 수 있습니다.
Azure에서는 동일한 난제와 상당한 복잡성에 직면하게 됩니다. 수천 대의 서버에서 수천 명의 엔지니어가 개발하고 유지 관리하는 소프트웨어를 실행하게 됩니다. 이러한 상황은 비즈니스 프로세스만으로는 관리할 수 없는 많은 공격 노출 표면을 야기합니다.
권한 부여 게이트 추가
Azure는 배포하는 소프트웨어의 보안, 규정 준수 및 품질에 대한 게이트를 구현하는 풍부한 엔지니어링 프로세스를 사용합니다. 이 프로세스에는 소스 코드에 대한 액세스 제어, 피어 코드 검토 수행, 보안 취약성에 대한 정적 분석 수행, Microsoft의 SDL(보안 개발 수명 주기) 준수, 기능 및 품질 테스트 수행이 포함됩니다. 배포하는 소프트웨어가 이 프로세스를 통과하도록 보장해야 합니다. 코드 무결성은 이러한 보장을 달성하는 데 도움이 됩니다.
권한 부여 게이트로 작용하는 코드 무결성
코드 무결성은 Windows Server 2016부터 사용할 수 있게 된 커널 수준 서비스입니다. 코드 무결성은 드라이버 또는 DLL(동적 연결 라이브러리)이 로드되거나, 실행 가능한 이진 파일이 실행되거나, 스크립트가 실행될 때마다 엄격한 실행 제어 정책을 적용할 수 있습니다. Linux의 경우 DM-Verity와 같은 유사한 시스템이 있습니다. 코드 무결성 정책은 이진 파일 또는 스크립트를 로드하거나 실행하기 전에 커널이 일치시키는 코드 서명 인증서 또는 SHA256 파일 해시와 같은 권한 부여 표시기 모음으로 구성됩니다.
코드 무결성을 사용하면 시스템 관리자가 특정 인증서로 서명되었거나 지정된 SHA256 해시와 일치하는 이진 파일 및 스크립트에만 권한을 부여하는 정책을 정의할 수 있습니다. 커널은 설정된 정책을 충족하지 않는 모든 작업의 실행을 차단하여 이 정책을 적용합니다.
코드 무결성 정책의 문제는 정책이 완벽하게 올바르지 않으면 프로덕션에서 중요한 소프트웨어를 차단하고 중단을 일으킬 수 있다는 것입니다. 이러한 문제가 있는 경우 보안 모니터링을 사용하여 권한 없는 소프트웨어가 실행된 시기를 감지하는 것만으로는 충분하지 않은 이유에 대해 의문이 생길 수 있습니다. 코드 무결성에는 실행을 방지하는 대신, 권한이 없는 소프트웨어가 실행될 때 경고할 수 있는 감사 모드가 있습니다. 경고는 규정 준수 위험을 해결하는 데 큰 가치가 있을 수 있지만 랜섬웨어 또는 사용자 지정 맬웨어와 같은 보안 위험이 있을 때는 몇 초만의 지연으로도 악의적 사용자가 공격 발판을 얻게 될 수 있습니다. Azure에서는 고객에게 영향을 미치는 중단을 가져오는 코드 무결성의 위험을 관리하기 위해 상당한 투자를 했습니다.
빌드 프로세스
위에서 설명한 것처럼 Azure 빌드 시스템에는 소프트웨어 변경이 안전하고 규정을 준수하는지 확인하기 위한 다양한 테스트 모음이 있습니다. 빌드가 유효성 검사를 통해 진행되면 빌드 시스템은 Azure 빌드 인증서를 사용하여 서명합니다. 이 인증서는 빌드가 전체 변경 관리 프로세스를 통과했음을 나타냅니다. 빌드가 거치는 최종 테스트를 CSV(코드 서명 유효성 검사)라고 합니다. CSV는 새로 빌드된 이진 파일이 프로덕션에 배포하기 전에 코드 무결성 정책을 충족하는지 확인합니다. 이렇게 하면 잘못 서명된 이진 파일로 인해 고객에게 영향을 미치는 중단이 발생할 확률이 크게 줄어듭니다. CSV에서 문제를 발견하면 빌드가 중단되고 관련 엔지니어는 문제를 조사하고 해결하도록 호출을 받습니다.
배포하는 동안 안전 유지
모든 빌드에 대해 CSV를 수행하지만 프로덕션의 일부 변경 또는 불일치로 인해 코드 무결성 관련 중단이 발생할 수 있습니다. 예를 들어, 머신이 이전 버전의 코드 무결성 정책을 실행하거나 코드 무결성에 대해 가양성을 생성하는 비정상 상태일 수 있습니다. (Azure 규모에서 우리는 모든 것을 보았습니다.) 따라서 배포 중 중단 위험으로부터 계속 보호해야 합니다.
Azure의 모든 변경은 일련의 단계를 통해 배포해야 합니다. 이중 첫 번째는 내부 Azure 테스트 인스턴스입니다. 다음 단계는 다른 Microsoft 제품 팀을 지원하는 데만 사용됩니다. 최종 단계는 타사 고객을 지원합니다. 변경이 배포되면 이러한 각 단계로 차례로 이동한 후 잠깐씩 멈추면서 스테이지의 상태를 측정합니다. 변경이 부정적인 영향을 미치지 않는 것으로 확인되면 다음 스테이지로 이동합니다. 코드 무결성 정책을 잘못 변경하면 스테이징된 이 배포 중에 변경이 검색되고 롤백됩니다.
인시던트 대응
계층화된 보호가 적용되더라도 여전히 그룹의 일부 서버가 적절히 허가된 소프트웨어를 차단할 수 있으며, 최악의 시나리오 중 하나로서 고객 관련 문제를 일으킬 수 있습니다. 최종 방어 계층은 사용자 조사입니다. 코드 무결성이 파일을 차단할 때마다 비상 대기 엔지니어가 조사해야 할 경고가 발생합니다. 이 경고를 통해 문제가 실제 공격, 가양성 또는 고객에게 영향을 미치는 기타 상황을 나타낼 경우 보안 조사를 시작하고 개입할 수 있습니다. 이렇게 하면 코드 무결성 관련 문제를 완화하는 데 걸리는 시간이 최소화됩니다.
다음 단계
Windows 10에서 구성 가능한 코드 무결성을 사용하는 방법을 알아봅니다.
플랫폼 무결성 및 보안을 추진하는 방법에 대한 자세한 내용은 다음을 참조하세요.