보안 설계 원칙
Well-Architected 워크로드는 보안에 대한 제로 트러스트 접근 방식으로 구축되어야 합니다. 안전한 워크로드는 공격에 대한 회복성이 뛰어나고 기밀성, 무결성, 가용성(CIA 3원칙이라고도 함)의 상호 연관된 보안 원칙을 통합하며, 비즈니스 목표를 충족합니다. 모든 보안 사고는 브랜드와 평판을 손상하는 중대한 침해로 이어질 가능성이 있습니다. 보안 전략이 작업 부하에 얼마나 잘 맞는지 평가하려면 다음 질문을 자문해 보세요.
- 귀사의 보안 대책은 공격자가 귀사의 작업 부하에 침입하는 것을 얼마나 늦추거나 막고 있나요?
- 공격이 발생할 경우 귀사의 보안 조치는 공격의 피해나 확산을 얼마나 제한하고 있나요?
- 공격자에게 당신의 작업 부하가 얼마나 중요할까요? 업무량이나 데이터가 도난당하거나, 사용할 수 없게 되거나, 변조된다면 기업에 얼마나 큰 손실이 될까요?
- 업무 중단을 얼마나 빨리 감지하고, 대응하고, 복구할 수 있나요?
시스템을 설계할 때 보안 위험을 완화하기 위한 나침반으로 Zero Trust 모델을 사용하세요. Microsoft
예상 위치에서 시작된 의도된 작업과 허용된 작업을 신뢰할 수 있는 ID만이 수행하도록 명확하게 확인하세요. 이 보호 장치를 사용하면 공격자가 합법적인 사용자와 계정을 가장하기가 더 어려워집니다.
적절한 기간 동안, 적절한 자산에 대해 적절한 권한 집합을 사용하여 적절한 신원에 대해 최소 권한 액세스를 사용하세요. 권한을 제한하면 공격자가 합법적인 사용자에게 필요하지 않은 권한을 남용하는 것을 방지하는 데 도움이 됩니다.
보안 통제가 위반될 것으로 가정하고 주요 방어 시스템이 실패할 경우 위험과 피해를 제한하는 보상 통제를 설계합니다. 그렇게 하면 성공에 관심이 있는 공격자처럼 생각하여(어떻게 성공하는지에 관계없이) 워크로드를 더 잘 방어하는 데 도움이 됩니다.
보안은 일회성 작업이 아닙니다. 이 지침을 반복적으로 구현해야 합니다. 공격자는 종종 자동화된 공격 키트를 사용하여 새로운 혁신적인 공격 벡터를 찾는 데 능숙하므로, 공격자로부터 업무 부하를 보호하다 막기 위해 지속적으로 방어 및 보안 지식을 강화하세요.
Microsoft Azure Well-Architected Framework에 기반한 설계 원칙은 위협이 진화함에 따라 워크로드의 보안 태세를 개선하는 데 도움이 되도록 지속적인 보안 사고방식을 육성하기 위한 것입니다. 이러한 원칙은 아키텍처, 설계 선택 사항 및 운영 프로세스의 보안을 안내해야 합니다. 권장되는 접근 방식부터 시작하여 일련의 보안 요구 사항에 대한 이점을 정당화하세요. 전략을 수립한 후, 다음 단계로 보안 체크리스트 를 활용하여 조치를 취하세요.
이러한 원칙이 제대로 적용되지 않을 경우 비즈니스 운영 및 수익에 부정적인 영향을 미칠 수 있습니다. 규제 워크로드에 대한 페널티와 같이 명백한 결과도 있을 수 있습니다. 그러나 덜 눈에 띄는 취약점도 있을 수 있으며, 감지되기 전에 지속적인 보안 문제를 일으킬 수도 있습니다.
많은 미션 크리티컬 워크로드에서는 데이터 반출과 같은 일부 공격 벡터가 안정성에 영향을 미치지 않는다는 점을 고려하면 안정성과 함께 보안이 주요 관심사입니다. 보안에 중점을 둔 설계는 장애 지점을 발생시키고 운영 복잡성을 증가시킬 수 있기 때문에 보안과 안정성은 서로 반대 방향으로 워크로드를 끌어당길 수 있습니다. 보안이 신뢰성에 미치는 영향은 운영상의 제약으로 인해 간접적으로 나타나는 경우가 많습니다. 보안과 안정성 간의 균형을 신중하게 고려하십시오.
이러한 원칙을 따르면 보안 효율성을 향상하고 워크로드 자산을 강화하며 사용자와의 신뢰를 구축할 수 있습니다.
보안 준비 상태 계획
최소한의 마찰로 아키텍처 설계 결정과 운영에서 보안 관행을 채택하고 구현하는 것을 목표로 합니다. |
---|
작업 부하 소유자로서 귀하는 조직에 대한 자산을 공유 책임으로 관리해야 합니다. 회사의 우선순위에 맞는 보안 준비 계획을 세우세요. 이는 명확한 프로세스, 충분한 투자, 적절한 책임을 확립하는 데 도움이 될 것입니다. 계획에서는 조직에 대한 업무 부하 요구 사항을 전달해야 하며, 조직은 자산을 보호할 책임도 공유해야 합니다. 보안 계획은 신뢰성, 건강 모델링, 자체 보호 전략의 일부가 되어야 합니다.
Azure Well-Architected Framework에서 보안 준비 계획 에 대해 자세히 알아보세요.
기밀성 보호를 위한 디자인
접근 제한 및 난독화 기술을 사용하여 개인 정보, 규정, 애플리케이션 및 독점 정보의 노출을 방지합니다. |
---|
워크로드 데이터는 사용자, 사용량, 구성, 규정 준수, 지적 재산 등을 기준으로 분류할 수 있습니다. 공유를 실행하거나 확립된 신뢰 경계를 넘어서 해당 데이터에 액세스해서는 안 됩니다. 보호하다 기밀성을 유지하려면 액세스 제어, 불투명성, 데이터와 시스템과 관련된 활동에 대한 감사 추적을 유지하는 데 중점을 두어야 합니다.
Azure Well-Architected Framework에서 레이어 기밀성을 설계하는 방법 에 대해 자세히 알아보세요.
무결성 보호를 위한 디자인
시스템이 예상 가치를 제공하지 못하거나 정의된 한도를 벗어나 작동하게 하는 중단을 예방하려면 설계, 구현, 운영 및 데이터가 손상되지 않도록 방지하세요. 시스템은 워크로드 수명 주기 전반에 걸쳐 정보 보증을 제공해야 합니다. |
---|
핵심은 비즈니스 로직, 흐름, 배포 프로세스, 데이터, 심지어 운영 체제와 부팅 시퀀스 같은 하위 스택 구성 요소의 변조를 방지하는 컨트롤을 사용하는 것입니다. 무결성이 부족하면 기밀성과 가용성이 침해될 수 있는 취약점이 발생할 수 있습니다.
Azure Well-Architected Framework에서 보호하다 무결성을 설계하는 방법 에 대해 자세히 알아보세요.
가용성 보호를 위한 디자인
강력한 보안 제어를 통해 보안 사고가 발생할 경우 시스템 및 작업 부하의 가동 중단 및 저하를 방지하거나 최소화하세요. 사고 발생 중과 시스템이 복구된 후에도 데이터 무결성을 유지해야 합니다. |
---|
가용성 아키텍처 선택과 보안 아키텍처 선택의 균형을 맞춰야 합니다. 시스템은 사용자가 데이터에 접근할 수 있고, 데이터에 접근할 수 있음을 보장하기 위해 가용성 보장을 제공해야 합니다. 보안 관점에서 볼 때 사용자는 허용된 액세스 범위 내에서 작업해야 하며 데이터를 신뢰할 수 있어야 합니다. 보안 제어는 나쁜 행위자를 막아야 하지만, 합법적인 사용자가 시스템과 데이터에 액세스하는 것을 막아서는 안 됩니다.
Azure Well-Architected Framework에서 보호하다 가용성을 설계하는 방법 에 대해 자세히 알아보세요.
보안 태세 유지 및 발전
공격 전략을 끊임없이 발전시키는 공격자보다 앞서 나가기 위해 지속적인 개선을 포함하고 경계를 강화합니다. |
---|
시간이 지나도 보안 태세가 약화되어서는 안 됩니다. 새로운 침해 사고가 보다 효과적으로 처리될 수 있도록 보안 운영을 지속적으로 개선해야 합니다. 업계 표준에 의해 정의된 단계로 맞추다 개선을 목표로 합니다. 그렇게 하면 대비 태세가 강화되고, 사고 감지 시간이 단축되며, 효과적인 봉쇄 및 완화가 가능해집니다. 지속적인 개선은 과거 사건에서 얻은 교훈을 바탕으로 이루어져야 합니다.
더 알아보기 보안 태세 유지 및 발전 Azure Well-Architected Framework에서.