Well-Architected 워크로드는 보안에 대한 제로 트러스트 접근 방식으로 구축되어야 합니다. 안전한 워크로드는 공격에 대한 회복력이 뛰어나고 기밀성, 무결성, 가용성(CIA 3대 원칙이라고도 함)의 상호 연관된 보안 원칙을 통합하며, 비즈니스 목표를 충족합니다. 모든 보안 사고는 브랜드와 평판을 손상시키는 중대한 침해로 발전할 가능성이 있습니다. 보안 전략이 업무에 얼마나 적합한지 평가하려면 다음 질문에 답해보세요.
- 귀사의 보안 조치는 공격자가 귀사의 작업에 침입하는 것을 얼마나 늦추거나 막고 있습니까?
- 공격이 발생할 경우, 귀사의 보안 조치는 공격의 피해나 확산을 얼마나 제한하고 있습니까?
- 공격자에게 귀하의 작업 부하가 얼마나 중요합니까? 업무량이나 데이터가 도난당하거나, 사용할 수 없게 되거나, 변조된다면 회사에 얼마나 큰 피해가 있을까요?
- 업무 중단을 얼마나 빨리 감지하고 대응하고 복구할 수 있나요?
시스템을 설계할 때 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에서.