보안 전략 정의

보안 조직의 궁극적인 목표는 클라우드 서비스 채택으로도 달라지지 않지만 이러한 목표를 달성하는 방법은 변경됩니다. 보안 팀은 여전히 모든 정보 시스템 및 데이터에 기본 제공되는 기밀성, 무결성 및 가용성을 확보하기 위해 공격에 따른 비즈니스 위험을 줄이는 데 집중해야 합니다.

보안 전략 현대화

보안 팀은 조직이 클라우드를 채택하고 지속적으로 운영하면서 전략, 아키텍처 및 기술을 현대화해야 합니다. 처음에는 변경의 규모와 횟수 때문에 어려워 보일 수 있지만 보안 프로그램을 현대화하면 보안 팀은 레거시 접근 방식과 관련된 몇 가지 어려운 문제를 줄일 수 있습니다. 조직은 일시적으로는 레거시 전략 및 도구를 사용하여 운영할 수 있지만 클라우드 및 위협 환경의 변화 속도를 고려할 경우 이 접근 방식을 유지하기는 어렵습니다.

• 보안 팀이 IT 및 비즈니스 팀과 협력하여 비즈니스를 진행하면서 위험을 줄이는 대신, 항상 “아니요”로 답변하면서 “거리를 유지하는” 보안을 나타내는 레거시 사고방식을 사용한다면 클라우드 채택 의사 결정에서 제외될 수 있습니다.
• 보안 팀은 레거시 온-프레미스 도구만 사용하고 모든 방어 및 모니터링에 대한 네트워크 경계 전용 규정만 따를 경우 클라우드 공격을 감지하고 방어하는 데 어려움을 겪게 됩니다.

클라우드 스케일 모니터링 및 보호

클라우드 스케일 방어는 클라우드 네이티브 검색 및 자동화 기능의 사용을 의무화하고 클라우드 및 모바일 자산을 모니터링하고 보호하는 데 도움이 되는 ID 경계를 도입하는 중요한 변환 작업입니다.

• Microsoft ID 플랫폼은 최신 인증 및 권한 부여 메커니즘을 애플리케이션에 통합하는 데 도움이 됩니다.
• Microsoft Sentinel은 조직 전체에서 클라우드 네이티브 보안 분석 및 위협 인텔리전스를 제공하여 위협 인텔리전스의 대규모 리포지토리를 사용하는 향상된 위협 탐지와 거의 제한없는 클라우드 처리 및 스토리지 기능을 제공합니다.

보안 팀은 보안 현대화에 대한 민첩한 접근 방식을 사용하는 것이 좋습니다. 즉, 전략의 가장 중요한 측면을 빠르게 현대화하고 지속적으로 서서히 개선해 가는 것이 좋습니다.

클라우드 보안 및 클라우드의 보안

조직에서 클라우드 서비스를 채택함에 따라 보안 팀은 다음 두 가지 주요 목표를 위해 노력합니다.

• 클라우드 보안(클라우드 리소스 보안): 이러한 핵심 보안 보증이 모든 리소스에 일관되게 적용되도록 클라우드 서비스의 계획 및 운영에 보안을 통합해야 합니다.
• 클라우드의 보안(클라우드를 사용하여 보안 변환): 보안 팀은 클라우드 기술을 사용하여 보안 도구와 프로세스, 특히 고유하게 통합된 보안 도구를 현대화하는 방법을 심사숙고하고 계획해야 합니다. 보안 도구는 점점 더 많은 경우에 클라우드에서 호스트되고 있습니다. 따라서 온-프레미스 환경에서는 어렵거나 불가능한 기능을 제공합니다.

소프트웨어 정의 데이터 센터 보안

많은 조직은 클라우드 리소스를 클라우드 보안을 위한 효과적인 시작점인 다른 가상 데이터 센터로 생각하는 것으로 시작합니다. 조직은 이 클라우드의 보안을 사용하여 현대화함에 따라 대부분의 조직은 이 사고 모델을 빠르게 능가할 수 있다는 사실을 알게 될 것입니다. 소프트웨어 정의 데이터 센터를 보호하면 온-프레미스 모델에서 제공할 수 있는 것 이상의 기능을 사용할 수 있습니다. 클라우드 호스팅 보안 도구는 다음을 제공합니다.

• 보안 기능의 신속한 사용 및 스케일링
• 매우 효과적인 자산 인벤토리 및 보안 구성 예방 검색

클라우드용 Microsoft Defender를 배포하면 조직의 보안 상태 및 제어를 지속적으로 평가할 수 있습니다. 클라우드 리소스의 보안 상태를 강화하고, 통합된 Microsoft Defender 계획을 통해 Defender for Cloud에서 Azure, 하이브리드 및 기타 클라우드 플랫폼에서 실행되는 워크로드를 보호합니다. 클라우드용 Microsoft Defender에 대해 자세히 알아보세요.

적절한 수준의 보안 마찰

보안은 프로세스 속도를 저하시키는 마찰을 발생시키며, DevOps 및 IT 프로세스에서 정상 상태인 요소와 그렇지 않은 요소를 식별하는 것이 중요합니다.

• 정상적인 마찰: 운동 저항이 근육을 더 강하게 만드는 것처럼, 적절한 수준의 보안 마찰을 통합하면 적시에 비판적 사고를 수행하게 되므로 시스템이나 애플리케이션이 강화됩니다. 일반적으로 이를 통해 공격자가 디자인 중에 애플리케이션 또는 시스템을 손상시키는 방법 및 이유를 고려하고(위협 모델링이라고 함), 공격자가 소프트웨어 코드, 구성 또는 운영 사례에서 악용할 수 있는 잠재적 취약성을 검토, 식별 및 이상적으로 수정하는 체계가 구성됩니다.
• 비정상적인 마찰: 보호하는 것보다 더 많은 가치를 훼손합니다. 이러한 상황은 도구에서 생성된 보안 버그에 가양성(예: 거짓 경보)이 높거나, 보안 문제를 검색 또는 수정하려는 노력이 공격의 잠재적 영향을 훨씬 넘어서는 경우에 자주 발생합니다.

독립 실행형 및 통합 책임

기밀성, 무결성 및 가용성 보증을 제공하려면 보안 전문가가 전용 보안 기능을 운영하고 조직의 다른 팀과 긴밀히 협력해야 합니다.

• 고유한 보안 기능: 보안 팀은 보안 작업, 취약성 관리(예: 가상 머신, 컨테이너) 및 기타 기능과 같이 조직의 다른 위치에서 찾을 수 없는 독립적인 기능을 수행합니다.
• 보안을 다른 기능에 통합: 또한 보안 팀은 비즈니스 이니셔티브를 주도하고, 위험을 평가하고, 애플리케이션을 설계 또는 개발하고, IT 시스템을 운영하는 조직의 다른 팀과 기능에 대한 실무 전문가 역할을 합니다. 보안 팀은 이러한 팀에 공격자에 대한 전문 지식과 컨텍스트, 공격 방법 및 추세, 무단 액세스를 허용할 수 있는 취약성, 완화 단계 또는 해결 방법에 대한 옵션과 잠재적 장단점을 제공합니다. 이 보안 기능은 단일 결과를 위해 크고 작은 지원이 제공되는 많은 위치에 얽혀 있으므로 품질 함수와 유사합니다.

클라우드의 빠른 변화 속도와 비즈니스 혁신을 따라가면서 이러한 책임을 이행하려면 보안 팀은 도구, 기술 및 프로세스를 현대화해야 합니다.

변환, 사고방식 및 기대

많은 조직에서는 조직의 여러 동시 변환 체인을 관리하고 있습니다. 이러한 내부 변환은 일반적으로 거의 모든 외부 시장이 모바일 및 클라우드 기술에 대한 새로운 고객 기본 설정에 맞게 변화하기 때문에 시작됩니다. 조직은 종종 새로운 신생 기업의 경쟁적 위협과 시장을 방해할 수 있는 기존 경쟁업체의 디지털 전환에 직면하게 됩니다.

내부 변환 프로세스에는 일반적으로 다음이 포함됩니다.

• 새로운 기회를 포착하고 디지털 네이티브 신생 기업에 대한 경쟁력을 유지하기 위한 비즈니스의 디지털 변환
• 클라우드 서비스, 현대화된 개발 사례 및 관련 변경으로 이니셔티브를 지원하기 위한 IT 조직의 기술 변환
• 클라우드에 적응하고 동시에 점점 더 정교해지는 위협 환경을 해결하기 위한 보안 변환

내부 충돌은 비용이 많이 들 수 있습니다.

변화는 스트레스와 갈등을 야기하여 결과적으로 의사 결정이 중단될 수 있습니다. 특히 보안 위험에 대한 책임이 비즈니스 결과 및 기타 모든 위험 유형에 대한 책임이 있는 자산의 소유자(비즈니스 소유자)가 아닌 주제 전문가(보안 팀)에게 잘못 부과되는 보안 팀에서 특히 그렇습니다. 이러한 잘못된 책임은 종종 모든 이해 관계자가 보안을 기업 스파이 및 기타 전형적인 범죄 활동과 같은 역동적으로 지속되는 위험이 아닌 해결해야 할 기술적 또는 절대적인 문제로 잘못 간주하기 때문에 발생합니다.

이러한 전환 기간 동안 모든 팀의 리더십은 중요한 프로젝트를 중단하고, 팀이 보안 위험 완화를 우회하도록 촉진할 수 있는 충돌 상황을 줄이기 위해 적극적으로 노력해야 합니다. 팀 간의 상충되는 충돌로 인해 다음이 발생할 수 있습니다.

• 피할 수 있는 보안 인시던트 또는 공격으로 인한 비즈니스 손상 증가와 같은 높아지는 보안 위험(특히 팀이 보안으로 인해 짜증을 느끼고 정상적인 프로세스를 우회하거나 공격자가 오래된 보안 접근 방식을 쉽게 우회할 때)
• 비즈니스 프로세스가 시장 요구를 충족할 만큼 빠르게 활성화되거나 업데이트되지 않는 경우(종종 보안 프로세스가 주요 비즈니스 이니셔티브를 방해하는 경우) 등에 비즈니스 또는 업무에 대한 부정적인 영향.

중요한 팀 구성원이 안전하지 않은 불안정한 상태가 되도록 할 수 있는 환경 변화를 알아내는 데 도움이 되도록 팀 내 및 팀 간의 관계 상태를 인식하는 것이 중요합니다. 이러한 사고방식에 대한 인내, 공감, 교육과 미래의 긍정적인 잠재력은 팀이 이 기간을 주의깊게 살펴보면서 조직을 위해 적절한 보안 결과를 이끌어내는 데 도움이 될 것입니다.

리더는 다음과 같은 구체적인 사전 조치를 통해 문화 변화를 주도할 수 있습니다.

• 팀에 기대하는 동작을 공개적으로 모델링합니다.
• 적응하기 위한 노력을 강조하는 것을 포함하여 변화에 대한 도전을 투명하게 공개합니다.
• 보안을 현대화하고 통합하는 일이 얼마나 긴급하고 중여ㅛ한지를 팀에게 정기적으로 상기시켜 줍니다.

사이버 보안 복원력

많은 클래식 보안 전략은 공격 방지에만 중점을 두어 왔습니다. 이러한 방식은 최신 위협을 극복하는 데는 충분하지 않습니다. 보안 팀은 이러한 수준을 넘어서는 전략을 세우고 신속한 공격 탐지, 대응 및 복구를 통해 복원력을 높일 수 있도록 해야 합니다. 조직은 공격자가 일부 리소스를 손상시킬 수 있다고 가정하고(위반 가정이라고도 함) 공격 방지와 공격 관리 간에 균형을 유지하면서 리소스 및 기술 설계를 진행해야 합니다(공격을 방지하기 위한 일반적인 기본 접근 방식이 아님).

많은 조직이 최근 몇 년 동안 지속적으로 증가하는 공격의 볼륨과 정교함을 관리해 왔기 때문에 이미 이 여정을 시작했다고 할 수 있습니다. 이 여정은 종종 사람들이 공격당하지 않으며 안전하다는 이전 감각을 상실한 감정적 이벤트가 될 수 있는 첫 번째 주요 인시던트로 시작됩니다. 생명을 잃은 것만큼 심각하지는 않지만, 이 이벤트는 거부로 시작하여 궁극적으로는 수용하게 되는 유사한 감정을 트리거할 수 있습니다. 이러한 “실패”라는 가정은 처음에는 일부 사용자가 수용하기는 어려울 수 있지만, 잘 설정된 “페일 세이프” 엔지니어링 원칙과 매우 유사하며, 팀이 성공에 대한 더 나은 정의로 볼 수 있는 회복에 주력할 수 있도록 합니다.

NIST 사이버 보안 프레임워크의 기능은 복원력 전략에서 식별, 보호, 감지, 대응 및 복구로 이루어진 보완 활동 사이에서 투자의 균형을 맞추는 방법에 대한 유용한 가이드 역할을 합니다.

사이버 보안 복원력 및 사이버 보안 제어의 궁극적인 목표에 대한 자세한 내용은 조직의 위험을 낮추는 방법을 참조하세요.

클라우드에서 보안이 달라지는 방식

보안을 위해 클라우드로 전환하는 것은 단순한 기술 변화 이상의 작업이며, 메인프레임에서 데스크톱 및 엔터프라이즈 서버로 이동하는 것과 유사한 세대적인 기술 변화입니다. 이러한 변경을 성공적으로 이해하려면 보안 팀은 기대 수준과 사고방식을 근본적으로 바꾸어야 합니다. 올바른 사고방식과 기대 수준을 채택하면 조직 내의 갈등이 줄어들고 보안 팀의 효율성이 높아집니다.

이러한 과정은 보안 현대화 계획의 일부일 수 있지만 클라우드의 빠른 변화 속도는 채택 자체를 최우선 과제로 삼고 있습니다.

• 공유 목표와의 파트너십. 의사 결정이 빠르게 진행되고 프로세스가 지속적으로 진화하는 이러한 시대에 보안은 더 이상 환경 변화를 승인하거나 거부하는 “거리 유지” 접근 방식을 채택할 수 없습니다. 보안 팀은 비즈니스 및 IT 팀과 긴밀히 협력하여 생산성, 안정성 및 보안과 관련하여 공유 목표를 수립하고, 이를 달성하기 위해 해당 파트너와 공동으로 협력해야 합니다.

  이 파트너십은 보안 문제를 보다 쉽고 효과적으로 해결하기 위해 프로세스 초기에 보안을 통합하는 원칙에 해당하는 궁극적인 “방임” 형태를 형성합니다. 이를 위해 모든 관련자(보안, 비즈니스 및 IT)의 문화권 변경이 필요하며, 각 그룹은 다른 그룹의 문화와 규범을 배우는 동시에 자신의 문화와 규범을 다른 그룹에 교육해야 합니다.

  보안 팀은 다음을 수행해야 합니다.

  • 비즈니스 및 IT 목표와 각 목표가 중요한 이유 및 이러한 목표를 달성하는 방법에 대해 배웁니다.
  • 이러한 비즈니스 목표와 위험의 맥락에서 보안이 중요한 이유, 다른 팀이 보안 목표를 달성하기 위해 수행할 수 있는 작업 및 보안 목표를 달성하는 방법을 공유합니다.

  쉬운 일은 아니지만 조직과 자산을 지속 가능하게 보호하는 것이 필수적입니다. 이 파트너십을 따를 경우 초기에는 최소한의 보안, 비즈니스 및 안정성 목표만 충족될 수 있지만 시간이 지남에 따라 점진적으로 개선되는 건전한 타협이 진행될 수 있습니다.

• 보안은 문제점이 아닌 지속적인 위험입니다. 여러분은 범죄를 “해결”할 수 없습니다. 핵심을 들여다보면 보안은 자연적인 이벤트가 아닌 인간의 악의적인 행동에 초점을 맞추는 위험 관리 분야일 뿐입니다. 모든 위험과 마찬가지로 보안은 솔루션으로 해결할 수 있는 문제가 아니며, 부정적인 이벤트, 공격으로 인한 손상의 가능성과 영향을 조합한 것입니다. 조직이 금전적인 측면에서 조직을 공격할 동기가 있는 인간 공격자의 공격을 받게 되는 전형적인 기업 스파이 및 범죄 활동과 가장 유사하다고 볼 수 있습니다.

• 생산성 또는 보안 측면에서 성공하려면 둘 다 필요합니다. 조직은 오늘날의 “혁신 또는 중요성이 감소되는” 환경에서 보안과 생산성 모두에 집중해야 합니다. 조직이 생산적이지 않고 새로운 혁신을 주도하지 못할 경우 시장에서 경쟁력을 상실하여 재정적으로 약화되거나 결국 실패할 수 있습니다. 조직이 안전하지 않고 공격자에 대한 자산 제어권을 상실하면 시장에서 경쟁력을 상실하여 재정적으로 약화되고 결국 실패할 수 있습니다.

• 누구도 완벽하지 않습니다. 어떤 조직도 클라우드를 완벽하게 채택할 수는 없으며 Microsoft도 마찬가지입니다. Microsoft의 IT 및 보안 팀은 프로그램을 잘 구성하는 방법을 파악하고 레거시 소프트웨어와 최첨단 혁신을 균형 있게 지원하는 것과 같이 고객들이 직면하는 여러 동일한 해결 과제와 클라우드 서비스의 기술 격차 등을 겪고 있습니다. 이러한 팀은 클라우드를 보다 잘 운영하고 보호하는 방법을 배우면서, 이와 같은 문서를 통해 얻은 교훈을 IT 쇼케이스 사이트의 다른 사용자와 적극적으로 공유하며, 엔지니어링 팀과 타사 공급업체에 지속적으로 피드백을 제공하여 제품 개선에 도움을 주고 있습니다.

  우리의 경험을 바탕으로 팀은 완벽의 표준보다는 지속적인 학습과 개선의 표준을 유지하는 것이 좋습니다.

• 변환의 기회. 디지털 변환을 보안을 위한 긍정적인 기회로 보는 것이 중요합니다. 이러한 변화의 잠재적 단점과 위험을 쉽게 알 수 있지만, 보안의 역할을 변환하고 의사 결정 권한을 얻게 되는 엄청난 기회를 놓치기 쉽습니다. 비즈니스와 파트너 관계를 맺으면 보다 많은 보안 자금을 확보하고, 보안과 관련된 낭비성 반복 작업을 줄일 수 있으며, 보안 작업이 조직의 업무와 좀 더 밀접하게 연결될수록 더욱 즐겁게 작업할 수 있게 됩니다.

공유 책임 모델 채택

클라우드에서 IT 서비스를 호스팅하면 클라우드 공급자와 고객 테넌트 간에 워크로드와 관련된 운영 및 보안 책임이 분할되어, 실제로 공동 책임 방식으로 파트너십이 형성됩니다. 모든 보안 팀은 프로세스, 도구 및 기술 세트를 새로운 세계에 맞게 조정하기 위해 이 공동 책임 모델을 연구하고 이해해야 합니다. 이렇게 하면 실수로 발생하는 보안 상태의 틈새 또는 중복을 방지함으로써 보안 위험 발생이나 리소스 낭비를 방지할 수 있습니다.

이 다이어그램은 사실상의 파트너 관계를 통해 클라우드 공급업체와 클라우드 고객 조직 간에 보안 책임을 분산하는 방법을 보여 줍니다.

클라우드 서비스의 모델이 다르기 때문에 각 워크로드에 대한 책임은 SaaS(Software as a Service), PaaS(Platform as a Service), IaaS(Infrastructure as a Service) 또는 온-프레미스 데이터 센터에서 호스팅되는지 여부에 따라 달라집니다.

보안 이니셔티브 작성

이 다이어그램에서는 대부분의 보안 프로그램이 클라우드에 대한 보안 전략 및 보안 프로그램 목표를 조정하기 위해 따라야 하는 세 가지 기본 보안 이니셔티브를 보여 줍니다.

클라우드에서 복원력 있는 보안 상태를 구축하려면 다음과 같은 몇 가지 병렬 보완 방법이 필요합니다.

• 신뢰하되 확인: 클라우드 공급자가 수행하는 책임의 경우 조직은 “신뢰하되 확인” 접근 방식을 따라야 합니다. 조직은 클라우드 공급자가 조직의 보안 요구 사항을 충족하는지 확인하기 위해 클라우드 공급자의 보안 사례와 클라우드 공급자가 제공하는 보안 제어를 평가해야 합니다.

• 인프라 및 애플리케이션 보안 현대화: 조직이 제어하는 기술 요소의 경우 클라우드에서 리소스를 보호하기 위한 적용 범위 격차를 최소화하기 위해 보안 도구 및 관련 기술 집합의 현대화를 우선적으로 수행합니다. 이 작업은 다음과 같은 두 가지 상호 보완 작업으로 구성됩니다.

  • 인프라 보안: 조직은 클라우드를 사용하여 운영 체제, 네트워크 및 컨테이너 인프라와 같은 많은 애플리케이션에서 사용하는 공통 구성 요소를 보호하고 모니터링하는 접근 방식을 현대화해야 합니다. 이러한 클라우드 기능은 종종 IaaS 및 온-프레미스 환경 모두에서 인프라 구성 요소 관리를 포함할 수 있습니다. 이 인프라는 인프라에서 실행되는 애플리케이션 및 데이터에 종속되며, 중요한 비즈니스 프로세스를 가능하게 하고 중요한 비즈니스 데이터를 저장하므로 이 전략을 최적화하는 것이 중요합니다.

  • 애플리케이션 보안: 또한 조직은 조직에서 또는 조직을 위해 개발한 고유한 애플리케이션 및 기술을 보호하는 방식을 현대화해야 합니다. 이 분야는 민첩한 DevOps 프로세스 채택, 오픈 소스 구성 요소의 사용 증가, 애플리케이션 구성 요소 또는 상호 연결 애플리케이션을 대체하는 클라우드 API 및 클라우드 서비스 도입으로 인해 빠르게 변화하고 있습니다.

    이러한 애플리케이션은 종종 중요한 비즈니스 프로세스를 사용하도록 설정하고 중요한 비즈니스 데이터를 저장하기 때문에 이러한 권리를 얻는 것이 중요합니다.

  • 최신 경계: 조직은 모든 워크로드에서 데이터를 보호하기 위한 포괄적인 접근 방식을 유지해야 하며, 중앙에서 관리되는 일관된 ID 컨트롤의 최신 경계를 설정하여 데이터, 디바이스 및 계정을 보호해야 합니다. 이것은 CISO 워크샵 모듈 3에서 자세히 논의된 제로 트러스트 전략의 영향을 많이 받습니다.

보안 및 신뢰

보안에서 신뢰라는 단어의 사용은 혼란을 일으킬 수 있습니다. 이 설명서에서는 이 개념의 유용한 응용 사례를 보여 주는 두 가지 방법으로 설명합니다.

• 제로 트러스트는 기업 또는 인트라넷 네트워크가 적대적(제로 트러스트에 적합)이고 그에 따라 보안을 설계한다고 가정하는 보안에 대한 전략적 접근 방식을 나타내는 일반적인 업계 용어입니다.
• 신뢰하되 확인은 잠재적으로 서로 다른 관심사가 있지만 공통의 목표를 향해 협력하는 두 조직의 본질을 나타내는 표현입니다. 이 표현은 조직을 위한 상용 클라우드 공급자와 파트너 관계를 맺는 초기 스테이지의 많은 세부 사항을 간결하게 포착합니다.

클라우드 공급자와 해당 사례 및 프로세스는 계약 및 규제 요구 사항을 충족할 책임이 있을 수 있으며 신뢰를 얻거나 잃을 수 있습니다. 네트워크는 공격자가 사용하는 경우 받아들일 수 없는 결과가 초래될 수 있는 살아 있지 않은 연결입니다(도로 또는 자동차를 사용하는 범죄자에게 책임을 물을 수 없는 것과 같음).

클라우드가 보안 관계 및 책임을 변경하는 방법

이전에 데스크톱 컴퓨팅 및 엔터프라이즈 서버 컴퓨팅과 같은 새로운 세대의 기술로 이전했던 것과 마찬가지로 클라우드 컴퓨팅으로의 전환은 오랫동안 확립된 관계, 역할, 책임 및 기술 집합에 지장을 주고 있습니다. 지난 수십 년 동안 익숙해진 작업 설명은 이제 클라우드 기능을 포함하는 기업에 명확하게 이해되지 않습니다. 업계가 새로운 모델을 정규화하기 위해 공동으로 작업함에 따라 조직은 이 변화의 기간 동안 모호성의 불확실성을 관리하는 데 도움이 되도록 가능한 한 명확성을 제공하는 데 집중해야 합니다.

보안 팀은 지원되는 비즈니스 및 기술의 이러한 변화와 위협 행위자의 행동 방향을 보다 잘 이끄는 자체적인 내부 현대화 작업의 영향을 받습니다. 공격자는 조직의 사람, 프로세스 및 기술에서 악용하기 쉬운 약점을 지속적으로 검색하기 위해 능동적으로 진화하고 있으며 보안은 이러한 차원의 문제를 해결하기 위해 기능과 기술을 개발해야 합니다.

이 섹션에서는 위험 최소화 및 개선 기회 수용과 관련해서 습득한 교훈을 포함하여 클라우드로 변환하는 여정에서 자주 변경되는 주요 관계에 대해 설명합니다.

• 보안 및 비즈니스 관련자 간: 보안 리더십은 조직이 위험을 줄일 수 있도록 비즈니스 리더와 점점 더 다각적으로 협력해야 합니다. 보안 리더는 SME(보안 주제 전문가)로서 비즈니스 의사 결정 수립을 지원해야 하며 이러한 비즈니스 리더의 신뢰할 수 있는 자문으로 성장하기 위해 노력해야 합니다. 이러한 관계는 비즈니스 리더가 비즈니스 결정을 내리는 동안 보안 위험을 고려하고, 비즈니스 우선 순위를 보안 팀에 알리고, 보안 투자가 다른 투자와 함께 적절하게 우선적으로 고려되도록 하는 데 도움이 됩니다.

• 보안 리더십과 팀 구성원 간: 보안 리더십은 투자 우선 순위를 안내하기 위해 비즈니스 리더십의 이러한 인사이트를 팀에 전달해야 합니다.

  보안 리더는 기존의 “거리를 유지하는” 관계보다는 비즈니스 리더 및 팀과의 협력 분위기를 조성함으로써 보안 및 생산성 목표를 모두 저해하는 적대적인 역동성을 방지할 수 있습니다.

  균형 잡힌 생산성 및 보안에 대한 일상적인 결정 사항을 관리하는 방법은 팀의 많은 사용자에게 생소한 사항일 수 있으므로 보안 리더는 이러한 정보를 명확하게 제공하려고 노력해야 합니다.

• 애플리케이션 및 인프라 팀(및 클라우드 공급자) 간: 이러한 관계는 혁신 속도와 개발자 생산성을 높이려는 IT 및 보안 업계의 여러 추세로 인해 상당한 변화를 겪고 있습니다.

  이전의 규범과 조직 기능은 중단되었지만 새로운 규범과 기능이 여전히 등장하고 있으므로, 모호성을 받아들이고, 현재의 사고방식을 따라가고, 이러한 결과를 얻을 때까지 조직에 적합한 작업을 실험해보는 것이 좋습니다. 조직이 주요 경쟁적 불이익을 받을 수 있으므로 이 분야에서는 그저 관망하는 자세를 취하는 것은 바람직하지 않습니다.

  이러한 추세는 애플리케이션 및 인프라의 역할 및 관계에 대한 기존의 규범에 맞지 않습니다.

  • DevOps 융합 분야: 이상적인 상태에서는 두 주제 전문가 세트를 결합하여 신속하게 혁신하고, 업데이트를 릴리스하고, 문제(보안 및 기타)를 해결하는 고도로 기능적인 단일 팀을 효과적으로 만듭니다. 이 이상적인 상태는 달성하는 데 다소 시간이 걸리고 중간 담당자의 책임은 여전히 모호하지만 조직은 이러한 협력적 접근 방식으로 인한 신속한 릴리스의 몇 가지 이점을 이미 얻고 있습니다. 보안을 이 주기에 통합하여 이러한 문화를 배우고, 보안 학습을 공유하고, 안전하고 신뢰할 수 있는 애플리케이션을 신속하게 릴리스한다는 공통의 목표를 향해 노력하는 것이 좋습니다.

  

  • 일반적인 인프라 구성 요소가 되어 가는 컨테이너화: 애플리케이션은 Docker, Kubernetes 및 유사한 기술로 점점 더 많이 호스트되고 오케스트레이션되고 있습니다. 이러한 기술은 기본 운영 체제의 설정 및 구성의 많은 요소를 추상화하여 개발 및 릴리스를 간소화합니다.

  

  컨테이너는 개발 팀에서 관리하는 애플리케이션 개발 기술로 시작했지만, 점점 더 많은 경우에 인프라 팀으로 전환하는 일반적인 인프라 구성 요소가 되고 있습니다. 이러한 전환은 여전히 많은 조직에서 진행 중이지만 현재 많은 난제들이 네트워킹, 스토리지 및 용량 관리와 같은 기존 인프라 기술 집합으로 가장 잘 해결될 수 있는 자연스럽고 긍정적인 방향이 나타나고 있습니다.

  이를 지원하는 인프라 팀 및 보안 팀 구성원에게는 이 기술을 관리, 모니터링 및 보호하는 데 도움이 되는 교육, 프로세스 및 도구를 제공해야 합니다.

  • 서버리스 및 클라우드 애플리케이션 서비스: 현재 업계에서 가장 지배적인 추세 중 하나는 애플리케이션을 빌드하거나 업데이트하는 데 필요한 시간과 개발 작업의 양을 줄이는 것입니다.

    

    또한 점점 더 많은 개발자들이 클라우드 서비스를 사용하여 다음을 수행하고 있습니다.

    • VM(가상 머신) 및 서버에서 애플리케이션을 호스팅하는 대신 코드를 실행합니다.
    • 자체 구성 요소를 개발하는 대신 애플리케이션 함수를 제공합니다. 이로 인해 일반적인 기능에 기존 클라우드 서비스를 사용하는 서버리스 모델이 나타나게 되었습니다. 또한 클라우드 서비스의 수와 다양성(및 혁신 속도)은 보안 팀이 이러한 서비스의 사용을 평가하고 승인하는 능력을 초과하게 되어, 개발자가 모든 서비스를 사용하도록 허용하거나, 개발 팀이 승인되지 않은 서비스를 사용하지 못하도록 하거나, 더 나은 방법을 찾기 위해 노력하는 경우 중에서 선택하게 됩니다.
    • 코드리스 애플리케이션 및 Power Apps: 또 다른 새로운 추세는 Microsoft Power Apps와 같은 코드리스 기술을 사용하는 것입니다. 이 기술을 사용하면 코딩 기술이 없는 사용자가 비즈니스 결과를 달성하는 애플리케이션을 만들 수 있습니다. 이러한 낮은 마찰과 높은 가치 잠재력으로 인해 이러한 추세는 빠르게 인기를 얻게 될 수 있으며 보안 전문가는 그 의미를 신속하게 이해하게 될 것입니다. 보안 작업은 사용자가 애플리케이션에서 실수를 할 수 있는 영역, 즉 애플리케이션 구성 요소, 상호 작용/관계 및 역할 권한에 대한 위협 모델링을 통해 애플리케이션 및 자산 권한의 설계에 중점을 두어야 합니다.

• 개발자와 오픈 소스 구성 요소 작성자 간: 개발자는 자체 구성 요소를 개발하는 대신 오픈 소스 구성 요소 및 라이브러리를 사용하여 효율성을 높이고 있습니다. 이렇게 하면 효율성을 통해 가치를 창출할 수 있지만, 외부 종속성을 만들고 해당 구성 요소를 적절히 유지 관리하고 패치해야 하는 상황을 만들어 보안 위험을 초래합니다. 개발자는 이러한 구성 요소를 사용할 때 보안 및 기타 버그의 위험을 효과적으로 가정하고, 개발하는 코드와 동일한 표준으로 완화할 계획이 있는지 확인해야 합니다.

• 애플리케이션과 데이터 간: 데이터 보안과 애플리케이션 간의 경계가 흐려지고 있으며 새로운 규정으로 인해 데이터/개인 정보 보호 팀과 보안 팀 간의 긴밀한 협력이 필요합니다.

  • 기계 학습 알고리즘: 기계 학습 알고리즘은 결과를 만들기 위해 데이터를 처리하도록 설계되었다는 측면에서 애플리케이션과 유사합니다. 주요 차이점은 다음과 같습니다.

    • 고부가가치 기계 학습: 기계 학습은 종종 상당한 경쟁적 우위를 차지하며 종종 민감한 지적 재산권 및 영업 비밀로 간주됩니다.

    • 중요도 임프린트: 감독되는 기계 학습은 알고리즘에 데이터 세트의 특성을 임프린트하는 데이터 세트를 사용하여 조정됩니다. 이로 인해 학습하는 데 사용되는 데이터 세트 때문에 조정된 알고리즘이 중요한 것으로 간주될 수 있습니다. 예를 들어 기계 학습 알고리즘을 학습하여 비밀 육군 기지 데이터 세트로 지도에서 비밀 육군 기지를 찾으면 중요한 자산이 됩니다.

    참고

    모든 예제가 명확하지는 않으므로 데이터 과학 팀, 비즈니스 이해 관계자, 보안 팀, 개인 정보 보호 팀 등의 적절한 이해 관계자와 팀을 구성하는 것이 중요합니다. 이러한 팀은 혁신과 책임이라는 공통의 목표를 달성할 책임이 있어야 합니다. 안전하지 않은 구성에서 데이터 복사본을 저장하는 방법과 저장 위치, 알고리즘을 분류하는 방법 및 조직의 우려 사항과 같은 일반적인 문제를 해결해야 합니다.

    Microsoft는 우리 팀과 고객을 안내하기 위한 책임 있는 AI 원칙을 발표했습니다.

    • 데이터 소유권 및 개인 정보: GDPR과 같은 규정은 데이터 문제 및 애플리케이션의 가시성을 향상시켰습니다. 이제 애플리케이션 팀은 은행 및 금융 기관의 재무 데이터 추적과 필적하는 수준에서 중요한 데이터를 제어, 보호 및 추적할 수 있습니다. 데이터 소유자 및 애플리케이션 팀은 데이터 애플리케이션이 저장하는 데이터 및 필요한 컨트롤을 보다 포괄적으로 이해해야 합니다.

• 조직과 클라우드 공급자 간: 조직은 클라우드에서 워크로드를 호스트하므로 각 클라우드 공급자와 비즈니스 관계를 맺게 됩니다. 클라우드 서비스를 사용하면 다음과 같은 비즈니스 가치를 얻는 경우가 많습니다.

  • 새로운 기능에 대한 출시 시간을 단축하여 디지털 혁신 이니셔티브를 가속화합니다.

  • 클라우드 서비스에서 팀을 대신하여 보다 효율적으로 제공하는 하위 수준의 상용 작업보다는 더 높은 가치(비즈니스에 직접적으로 관련된) 활동에 집중할 수 있도록 하여 IT 및 보안 활동의 가치를 높입니다.

  • 안정성 및 응답성 향상: 또한 대부분의 최신 클라우드는 기존 온-프레미스 데이터 센터에 비해 가동 시간이 높으며 빠르게 스케일링할 수 있으며(예: COVID-19 펜데믹 기간처럼), 번개와 같은 자연 이벤트 이후에 복원력을 제공할 수 있음을 보여주었습니다(온-프레미스의 많은 동급 기능이 훨씬 더 오랫동안 가동이 중단됨).

    유익하지만 클라우드로의 이러한 전환이 위험하지 않은 것은 아닙니다. 조직은 클라우드 서비스를 채택할 때 다음을 비롯한 잠재적 위험 영역을 고려해야 합니다.

  • 비즈니스 연속성 및 재해 복구: 클라우드 공급자는 조직에서 서비스를 사용하는 동안 지속되고 성장할 수 있는 비즈니스 모델로 재정적으로 정상적인 상태를 유지하나요? 클라우드 공급자가 재정적 또는 기타 실패를 경험하는 경우 고객 지속성을 허용하기 위해 고객에게 소스 코드를 제공하거나 오픈 소싱하는 등과 같은 프로비저닝을 수행했나요?

    Microsoft의 재정 상태에 대한 자세한 내용 및 문서는 Microsoft 투자자 관계를 참조하세요.

  • 보안: 클라우드 공급자는 보안에 대한 업계 모범 사례를 따르나요? 이러한 사실이 독립적인 규제 기관에 의해 검증되었나요?

    • 클라우드용 Microsoft Defender 앱을 사용하면 70개 이상의 위험 요소에 따라 순위 및 점수가 매겨진 16,000개 이상의 클라우드 애플리케이션에 대한 사용량을 검색하여 클라우드 사용, 섀도 IT 및 섀도 IT가 조직에 미치는 위험을 계속해서 파악할 수 있습니다.
    • Microsoft Service Trust Portal은 규정 준수 인증, 감사 보고서, 펜 테스트 등을 고객에게 제공합니다. 이러한 문서에는 내부 보안 사례(특히 SOC 2 유형 2 보고서 및 FedRAMP Moderate 시스템 보안 계획)에 대한 많은 세부 정보가 포함되어 있습니다. 클라우드용 Microsoft Defender에서는 보안 정책을 관리할 수 있으며 미리 정의된 산업 및 규정 표준에 대한 규정 수준 수준을 나타낼 수 있습니다.

  • 비즈니스 경쟁업체: 클라우드 공급자가 업계에서 중요한 비즈니스 경쟁업체인가요? 클라우드 서비스 계약의 충분한 보호 장치나 잠재적으로 악의적인 작업으로부터 비즈니스를 보호하기 위한 기타 수단이 있나요?

    Microsoft가 클라우드 고객과의 경쟁을 피하는 방법에 대한 설명을 보려면 이 문서를 검토하세요.

  • 다중 클라우드: 많은 조직에는 사실상 또는 의도적인 다중 클라우드 전략이 있습니다. 이것은 단일 공급업체에 대한 의존도를 줄이거나 고유한 최고 기능에 액세스하기 위한 의도적인 목표일 수 있지만, 개발자가 선호하거나 친숙한 클라우드 서비스를 선택했거나 조직에서 다른 비즈니스를 인수했기 때문에 발생할 수도 있습니다. 그 이유에 관계없이 이 전략은 다음을 포함하여 관리해야 하는 잠재적인 위험 및 비용을 초래할 수 있습니다.

    • 여러 종속성으로 인한 가동 중지 시간: 여러 클라우드에 의존하도록 설계된 시스템은 클라우드 공급자(또는 팀의 해당 공급자 사용)의 중단으로 인해 비즈니스 정지/중단이 발생할 수 있으므로 더 많은 가동 중지 시간 위험에 노출됩니다. 팀 구성원이 좀 더 복잡해진 시스템을 완전히 이해할 가능성이 적기 때문에 이와 같은 늘어난 시스템 복잡성은 중단 이벤트를 야기할 가능성도 높아집니다.
    • 협상 능력: 또한 대규모 조직에서는 단일 클라우드(상호 약정/파트너십) 또는 다중 클라우드 전략(비즈니스를 전환할 수 있는 능력) 중에서 어떤 측면이 클라우드 공급자가 조직의 기능 요청 우선 순위를 결정하는 데 더 큰 영향을 발휘할지를 고려해야 합니다.
    • 유지 관리 오버헤드 증가: IT 및 보안 리소스는 이미 기존 워크로드로 인해 과부하가 걸렸으며 단일 클라우드 플랫폼의 변경을 따르고 있습니다. 각 추가 플랫폼은 이러한 오버헤드를 더욱 증가시키고, 팀 구성원들은 비즈니스 혁신을 가속화하기 위한 기술 프로세스 간소화, 보다 효과적인 기술 사용을 위해 비즈니스 그룹과 협의하기 등과 같은 보다 가치 높은 작업에 집중하기 어려워집니다.
    • 직원 및 교육: 조직은 종종 여러 플랫폼을 지원하는 데 필요한 직원 요구 사항과 빠른 속도로 출시되는 새로운 기능에 대한 지식과 흐름을 유지하는 데 필요한 교육을 고려하지 않습니다.