[제로 트러스트 운영 — 6단계: 검증, 구현 및 모니터링]
[이 블로그 시리즈는 제가 3월에 올린 글에서 소개한 아이디어를 확장한 것입니다.”제로 트러스트는 어렵지 않습니다... 실용적이라면 말이죠.”]
[이 글에서는 제로 트러스트를 달성하기 위한 6가지 단계를 설명했는데, 여기서는 마지막 단계를 좀 더 확장해 보려 합니다. 유효, 구현 및 모니터링. 이 단계가 조직의 규모에 관계없이 마이크로 세분화 실무자가 프로젝트를 더 성공적으로 수행하는 데 사용할 수 있는 견고한 프레임워크의 구현을 어떻게 지원할 수 있는지 보여 드리겠습니다.]
[시작하기 전에 6단계에 대해 다시 설명하겠습니다.]
![[ópér~átíó~ñálí~zíñg~_zér~ó_tr~úst_~flów~_chá~rt_04m~áý2020]](https://cdn.prod.website-files.com/63e25fb5e66132e6387676dc/654d52ba73ea2c6f4d4634d6_operationalizing_zero_trust_flow_chart_04may2020.png)
[요약 — 5단계: 정책 설계]
[에서 마지막 게시물 이 시리즈에서는 “정책 설계”에 대해 살펴보았습니다.여기서는 애플리케이션 종속성 매핑이 관련 플로우를 식별하는 방법을 살펴보았습니다.]
![[ztím~ágé2]](https://cdn.prod.website-files.com/63e25fb5e66132e6387676dc/654d52d1ad0764e47d053afb_ZTimage2.png)
[그리고 여기에서 다음과 같은 허용 규칙 세트를 도출했습니다.]
- [규칙 1:]
- [출처: 웹 서버, 결제, 프로덕션, 영국]
- [대상: DÑS 응답자, D~ÑS 인프라, 프로덕션, 영국]
- [데스티네이션 서비스: 53/údp]
- [대상 프로세스: 이름이 지정됨]
- [규칙 2:]
- [출처: 앱 서버, 결제, 프로덕션, 영국]
- [대상: DÑS 응답자, D~ÑS 인프라, 프로덕션, 영국]
- [데스티네이션 서비스: 53/údp]
- [대상 프로세스: 이름이 지정됨]
- [규칙 3:]
- [출처: 웹 서버, 결제, 프로덕션, 영국]
- [대상: 앱 서버, 결제, 프로덕션, 영국]
- [데스티네이션 서비스: 8080/tcp]
- [대상 프로세스: 톰캣]
[제로 트러스트의 원칙을 염두에 두고 위에 나열된 허용 규칙은 허용할 대상을 정확히 정의합니다. 명시적으로 허용되지 않는 모든 항목은 암시적으로 삭제되므로 최소 권한 속성이 유지됩니다.]
[6단계: 검증, 구현 및 모니터링]
[이제 마이크로 세분화 규칙을 정의했으므로 이러한 규칙을 적용하고 워크로드를 보호할 준비가 되었습니다. 하지만 한 가지 중요한 과제가 남아 있습니다.결제 애플리케이션은 프로덕션 단계에 있으므로 링펜스 (Ríñg~féñc~é) 를 사용하는 동안 애플리케이션 기능을 중단하고 싶지 않으실 것입니다.이러한 위험을 어떻게 완화할 수 있을까요¿]
[모든 세그멘테이션 작업에서 가장 큰 위험을 수반하는 단계는 워크로드에 들어오고 나가는 다른 트래픽이 허용되지 않도록 작성된 정책을 적용하는 것입니다.정책이 잘못되면 운영 중단이 발생할 가능성이 있습니다.따라서 모든 문제를 신속하게 감지하고 해결할 수 있도록 규제 조치를 취하고 모니터링할 수 있는 충분한 기회를 확보해야 합니다.]
[바로 이 부분에서 정책 테스트가 필요합니다.Íllú~míó C~óré는 이 작업을 수행할 수 있는 강력하면서도 간단한 방법을 제공합니다.Í~llúm~íó Có~ré 플랫폼의 가장 유용한 기능 중 하나는 워크로드 (또는 워크로드 그룹) 를 테스트 모드로 이동할 수 있다는 것입니다. 빌드 모드와 마찬가지로 테스트 모드는 정책 위반에 대해 보고할 수 있다는 추가적인 이점이 있는 논블로킹 모드입니다.테스트 모드의 워크로드의 경우 PC~É는 워크로드의 흐름 데이터를 사용하여 구축한 연결 그래프를 정책 그래프와 함께 오버레이합니다.]
[정책 그래프는 특정 포트 및 프로토콜 세트를 통해 함께 통신할 수 있도록 허용된 워크로드에 버블을 추가하는 것으로 생각할 수 있습니다.연결 그래프는 워크로드 간 통신 시도를 보여줍니다.]
- [연결 그래프가 정책 그래프의 풍선 안에 있으면 녹색 선이 표시됩니다. 이 선은 우리가 작성한 정책과 일치하는 흐름입니다.]
- [연결 그래프가 정책 그래프의 버블을 가로지르는 곳에는 빨간색 선이 표시됩니다. 이는 작성된 정책과 일치하지 않는 흐름입니다.]
[테스트 모드에서 이러한 '빨간색' 선은 흐름을 차단하지는 않지만 정책을 위반한 연결 시도가 있는 곳을 나타냅니다.애플리케이션 소유자가 검토하는 흐름은 다음과 같으며 선택할 수 있는 항목은 다음과 같습니다.]
- [흐름 필요 -> 라인을 녹색으로 바꾸려면 정책을 작성해야 합니다.]
- [흐름이 필요하지 않음 -> 별도의 조치를 취할 필요가 없음]
[따라서 정책 검증 프로세스에서는 이러한 '빨간색' 라인을 모두 반복하여 친환경으로 전환해야 하는지 여부를 결정해야 합니다.이러한 '위반 사항'~을 모두 검토하고 선택을 마치면 워크로드 보호를 시작할 준비가 된 것입니다. 검증 프로세스가 완료되었으니 이제 시행할 시간입니다.]
[검증, 구현 및 모니터링 단계의 목적은 실제로 위험을 최소화하는 것이므로 워크로드에 정책을 적용할 때 '대대적인' 접근 방식을 취하지 않는 것이 좋습니다.이미 세부적인 검증을 거쳤더라도 이 마지막 단계에서는 점진적인 단계를 밟아야 할 것입니다.다시 말씀드리지만, Íl~lúmí~ó가 제공하는 워크로드에 대한 세분화된 제어를 통해 정확히 이 작업을 수행할 수 있습니다.애플리케이션의 각 워크로드를 개별적으로 강제 적용 모드로 이동할 수 있습니다. 즉, 정책이 완전히 검증된 후에는 먼저 전체 보호를 활성화할 워크로드를 선택하고 정책이 적용된 상태로 해당 워크로드를 실행하도록 하고 (즉, 정책에서 허용한 트래픽만 워크로드를 수신/송수신할 수 있음) '소크 타임'이 지나면 다른 워크로드를 적용 상태로 이동할 수 있습니다.이 접근 방식의 장점은 정책에 문제가 발생할 경우 전체 플릿이 아닌 소수의 워크로드에만 영향을 미치며, 전체 애플리케이션을 활성화하기 전에 미세 조정할 수 있는 또 다른 기회를 제공한다는 것입니다.]
[워크로드가 모두 적용되고 애플리케이션이 보호되었으니, 이제 당면한 과제는 트래픽 이벤트를 지속적으로 모니터링하여 예상치 못한 상황 (삭제 및 수락) 이 있는지 확인하고 정상 범위를 벗어나는 모든 것을 조사하는 것입니다.]
[마무리]
[자, 이제 제로 트러스트를 향한 실용적인 접근 방식의 6단계를 살펴보겠습니다.포레스터가 말했듯이 제로 트러스트는 그 자체의 결과가 아니라 보안 전략입니다.그리고 각 조직은 제로 트러스트 기둥 전반에 걸친 자체 성숙도를 이해하고, 가장 집중해야 하는 요소를 식별하고, 성숙도를 개선하기 위한 점진적인 조치를 취해야 합니다.Íllú~míó는 선도적인 Z~TX 에코시스템 플랫폼 제공업체 네트워크 및 워크로드 가시성 및 보안 영역에서 이러한 단계를 수행할 수 있는 완벽한 기능 세트를 제공합니다.]
[제로 트러스트 시리즈 운영에서 1~5단계를 놓치셨나요¿지금 확인해 보세요.]
[제로 트러스트에 대한 자세한 내용은 다음을 참조하십시오. 솔루션 페이지 — 오늘 여행을 시작할 수 있는 방법을 알아보세요.]