액세스 전략을 재고하세요, Think BeyondCorp

몇 년 전 , Forrester는 오래된 보안 구호인 "신뢰하되 검증하라"는 말이 사라졌다고 선언하고 제로 트러스트라는 용어를 만들어냈습니다. 이 주장은 초기의 성공적인 인증에 따라 모든 것을 신뢰했지만 그 이후로는 실제로 검증하지 않았다는 것입니다. 평소와 마찬가지로, 이런 유행어는 엄청난 기대로 시작하지만 단기적으로는 큰 반응으로 이어지지 않는 과대선전 주기를 거칩니다. 제로 트러스트와 그에 따른 파생 기술(애플리케이션이 새로운 경계 등)은 이제 실제 아키텍처와 구현에서 인기를 얻고 있습니다. 이러한 보안 전략의 강력한 지지자인 구글은 이를 구현하는 데 큰 진전을 이루었으며, 이를 구현하는 과정을 공개하기도 했습니다. 그들은 이것을 BeyondCorp라고 이름붙였습니다.

Google은 최근 해당 주제에 대한 4번째 연구 논문을 홍보하는 블로그 게시물을 게시했는데, 여기에는 긴 마이그레이션 과정을 거치면서도 생산성을 유지한 방법이 설명되어 있습니다. BeyondCorp 아키텍처를 요약하면, 온프레미스 액세스와 원격 액세스 사이에 더 이상 차이가 없습니다. 단지 액세스만 있을 뿐입니다. 모든 인증 및 액세스 요청은 사용자의 위치나 장치에 관계없이 중앙 액세스 게이트웨이를 통해 동일한 경로를 따릅니다. 그러나 인증 문제와 액세스 결정은 여러 위험 요소에 따라 달라질 수 있습니다. 게이트웨이는 인증 프롬프트를 제공할 뿐만 아니라 위험 프로필을 기반으로 하는 세분화된 속성 기반 액세스 제어도 허용합니다. 이를 통해 사용자는 일관성과 단순성을 확보할 수 있으며, 이는 공격이 성공할 가능성을 낮추는 데 매우 중요합니다(지난 글에서 설명했듯이).

예를 들어, 사용자가 회사 공지 사항만 있고 공개될 가능성이 있는(위험성 낮음) 회사 웹 앱에 연결하려고 하고, 사무실 책상이나 회사에서 지급한 노트북(위험성 낮음)에서 연결하려고 하는 경우, 보안 관리자로서 사용자 이름과 비밀번호만 입력하면 액세스할 수 있도록 선택할 수 있습니다. 하지만 사용자가 러시아 어딘가(고위험)에서, 그리고 알 수 없는 기기(고위험)에서 금융 관련 애플리케이션(고위험)에 연결하려고 한다고 가정해 보겠습니다. 보안 관리자인 저는 액세스 게이트웨이에 이러한 방식이 너무 위험하다고 판단하여 액세스를 거부하거나 최소한 사용자에게 2차 또는 3차 요소를 입력하여 신원을 확인하도록 하는 정책을 갖고 있을 수 있습니다. 더욱이 세분화된 속성 기반 액세스 제어를 통해 해당 위험 수준에 맞는 액세스 요청에 축소된 형태의 액세스, 즉 읽기/쓰기 대신 읽기 전용 권한을 부여하기로 결정할 수도 있습니다.

이 중에 여러분에게 익숙한 내용이 있나요? F5 파트너인 Microsoft Azure AD, Ping , Okta 등이 제공하는 IDaaS 서비스를 사용하고 있다면 이미 어느 정도 이러한 작업을 수행하고 있는 셈입니다. BeyondCorp 모델을 구성하는 다른 구성 요소도 있지만 액세스 게이트웨이가 확실히 전체 아키텍처의 핵심입니다. Google은 이제 다른 회사가 사용할 수 있는 "ID 인식 프록시"(IAP)를 제공하고 있지만 제한이 없는 것은 아닙니다. 이 기능을 Google Compute Platform(GCP)의 앱에서만 사용할 수 있다는 것 외에도, 일부 고객은 액세스 제어의 세부성과 유연성 측면에서 어려움을 겪었고, GCP가 아닌 애플리케이션 정책에 따라 구성 가능한 세션 길이를 원했으며, 유연한 단계별 2차 인증 기능을 원했습니다.

우연히도 F5는 이러한 기능을 비롯한 다양한 기능을 제공하는 액세스 솔루션을 제공합니다. 이 기능은 GCP 내에 있는 앱에만 적용되는 것이 아니라 모든 환경에서 작동합니다. 완전한 클라우드 방식이든 하이브리드 방식이든 F5는 모든 아키텍처에 맞는 안전하고 중앙 집중화되고 확장 가능한 액세스 솔루션을 제공합니다. 자세한 내용은 f5.com/apm을 방문하세요.