제로 트러스트의 진화
제로 트러스트는 지난 10년간 가장 많이 논의된 사이버 보안 모델 중 하나가 되었습니다. 하지만 많은 구현 사례들이 여전히 피상적인 수준에 머물러 있습니다.
조직들은 ID 공급자, MFA 솔루션, 엔드포인트 보안 도구를 배포하지만, 중요한 질문 하나를 간과합니다.
접근 권한 결정은 실제로 어디에서 시행되는가?
하이브리드 및 멀티 클라우드 환경에서는 기존의 네트워크 경계가 더 이상 존재하지 않습니다. 애플리케이션은 분산되어 있으며, API는 여러 지역에 걸쳐 통신하고, 워크로드는 동적으로 이동합니다.
이러한 현실에서 신원은 사용자 인증뿐만 아니라 트래픽 흐름을 제어하는 역할도 해야 합니다.
주변부 중심적 사고의 문제점
기존 보안이 가정됨:
- 신뢰할 수 있는 내부 네트워크
- 신뢰할 수 없는 외부 네트워크
- 방화벽은 경계를 강화합니다.
하지만 최신 아키텍처는 이러한 가정을 무효화합니다. 내부 트래픽이 손상될 수 있으며, 데이터 센터 내에서 횡적 이동이 발생할 수 있고, API 간 통신은 일반적인 공격 경로입니다.
제로 트러스트는 원칙을 바꿉니다.
절대 믿지 마라. 항상 검증하라. 지속적으로 시행하라.
정체성이 새로운 경계선이다
제로 트러스트 아키텍처에서 신원은 핵심 제어 변수가 됩니다.
- 사용자 ID
- 서비스 ID
- 기기 ID
- 워크로드 식별
하지만 신원 확인은 적절한 아키텍처 계층에서 이루어져야 합니다.
로그인 시에는 신원 확인이 이루어지지만 트래픽 처리 단계에서는 적용되지 않으면 정책 일관성이 깨집니다.
애플리케이션 전달 계층이 중요한 이유
애플리케이션 전달 계층은 다음 요소들의 교차점에 위치합니다:
- 사용자 액세스
- API 통신
- 클라우드 라우팅
- 백엔드 서비스 노출
이러한 특징 덕분에 이곳은 제로 트러스트를 시행하기에 이상적인 지점이 됩니다.
이 단계에서 조직은 다음과 같은 작업을 수행할 수 있습니다.
- 서비스 간 mTLS 적용
- ID별로 정책 기반 라우팅을 적용합니다.
- 레이어 7 트래픽을 검사합니다.
- 애플리케이션을 논리적으로 분할합니다.
- 측면 이동 방지
방법 RELIANOID 실질적인 제로 트러스트를 구현합니다
At RELIANOID우리는 제로 트러스트를 제품 기능이 아니라 애플리케이션 제공 영역에서 구현되는 아키텍처 원칙으로 간주합니다.
신원 인식 트래픽 제어
RELIANOID IP 주소뿐 아니라 신원 속성을 기반으로 접근 정책을 시행합니다.
mTLS 서비스 간
상호 TLS 인증은 클라이언트와 서버가 통신을 설정하기 전에 서로의 신원을 확인하도록 보장합니다.
레이어 7 정책 시행
애플리케이션 인식 검사를 통해 다음과 같은 요소에 기반한 세부적인 결정을 내릴 수 있습니다.
- JWT는 주장합니다
- 요청 헤더
- API 경로
- 사용자 역할
하이브리드 및 멀티 클라우드 일관성
제로 트러스트 정책은 온프레미스, 프라이빗 클라우드 및 퍼블릭 클라우드 환경 전반에 걸쳐 일관성을 유지해야 합니다. RELIANOID 전달 단계에서 시행을 중앙 집중화합니다.
제로 트러스트는 아키텍처적 사고를 요구합니다.
제로 트러스트는 단순히 도구를 추가하는 것으로 구현되는 것이 아닙니다. 이는 신원 정보가 트래픽과 상호 작용하는 방식을 재설계함으로써 달성됩니다.
현대 건축에서 전달 영역은 집행 영역이 된다.
트래픽 계층에서 신원 확인을 강화하는 것이 바로 제로 트러스트를 개념에서 실제 운영 현실로 전환하는 핵심입니다. 더 자세한 정보를 원하시면 저희에게 연락하십시오.
관련 블로그
