SSO/Rest 및 NGINX Plus로 Zero Trust 달성
IDF Connect의 SSO/Rest 플러그인이 NGINX Plus에 도입되면서 대용량 사이트 중 가장 널리 사용되는 웹 서버가 Zero Trust 보안 아키텍처의 핵심 구성 요소로 작동할 수 있습니다.
클라우드 컴퓨팅으로 이동함에 따라, 우리의 데이터, 운영 및 비즈니스 일부가 공개 인터넷을 대상으로 재배치되고 있습니다.
민감한 자산은 더 이상 기업 데이터 센터에 숨겨지지 않으며, 현장(on-site) 직원에게만 액세스할 수 있는 것이 아닙니다.
이러한 패러다임 변화로 인해 발생하는 새로운 위험은 점점 더 기존 액세스 제어 모델을 불충분하게 만들고 있으며 보안 커뮤니티가 보안에 대한 “제로 트러스트(Zero Trust)” 접근 방식을 리소스 보호를 위한 표준으로 빠르게 채택하고 있습니다.
Zero Trust 아키텍처에서는 기업의 내부 경계 안에서 신뢰할 수 있는 네트워크와 외부의 신뢰할 수 없는 세계가 더 이상 존재하지 않습니다. 대신 데이터와 자원 주변에 “마이크로 경계(microperimeters)”가 구축되어 모든 위치에서 세밀한 접근 제어 정책이 시행됩니다. (Zero Trust에 대한 자세한 논의는 목차 5를 참조하십시오.)
목차
1. NGINX Plus, Zero Trust 웹 액세스 관리의 핵심 구성 요소
2. NGINX Plus용 SSO/Rest 플러그인 구성
3. SSO/Rest 플러그인 작동
4. 강화, 보안, 단순화
5. Zero Trust WAM
6. Zero Trusy WAM, 결론
1. NGINX Plus, Zero Trust 웹 액세스 관리의 핵심 구성 요소
Zero Trust Web Access Management (WAM)가 완전히 효과적이 되기 위해서는 로드 밸런서 및 웹 서버의 가장 앞선 라인에서 시작되어야 합니다. NGINX Plus는 이러한 필수적인 보안 수준을 달성하기 위한 완벽한 시행 지점입니다. Front-end Web Layer는 환경의 자연적인 경계를 형성하며, 액세스 강제 적용을 시작하기에 완벽한 장소입니다.
하지만 이러한 보호를 경계선까지 확장하는 것은 도전적일 수 있습니다.
주요 WAM 공급업체 중 일부는 여전히 NGINX와 NGINX Plus를 지원하지 않습니다.
이는 기업의 WAM 플랫폼 보호를 유지하기 위해 오래된 웹 서버를 유지하거나 NGINX Plus 구성 요소를 완전히 활용하지 못하도록 하였다는 것을 의미합니다.
지금까지, 어떤 기업용 WAM 도구도 클라우드 배포 애플리케이션과 원활하게 작동하지 못했습니다.
다행히도 이제는 그렇지 않습니다. IDF Connect의 SSO/Rest 플러그인은 NGINX Plus와 원활하게 통합되어 기업 WAM 플랫폼의 모든 기능을 지원합니다. NGINX Plus 인증 모듈인 이 플러그인은 설치 및 구성이 간단하며, 최종 사용자와 관리자 모두에게 투명합니다.
클라우드용으로 최적화되어 가벼우며, 완전한 WAM 통합에 필요했던 무겁고, 수다스러운 WAM 에이전트를 대체합니다.
이 플러그인은 데이터 센터 깊숙한 위치의 인가 정책 결정 지점(PDP)과 안전하게 통신하기 위해 DMZ에 위치한 보안 강화 서버인 SSO/Rest Gateway와 함께 작동합니다.
SSO/Rest Plug-In과 Gateway는 함께 사용하여 모든 전통적인 기업용 WAM 도구에서 발생하는 클라우드 비호환성 문제를 해결합니다.
이는 기업이 이전에 가지고 있던 WAM 플랫폼의 모든 기능, 단일 로그인, 인증 및 액세스 제어 강화를 활용하여 애플리케이션을 클라우드로 이전할 수 있음을 의미합니다.
이러한 해결책은 온프레미스 IAM 솔루션을 철저히 교체하고 대체하는 과정 없이 기존 요구 사항을 클라우드 기반 애플리케이션에 맞게 조정할 수 있도록 도와줍니다.
2. NGINX Plus용 SSO/Rest 플러그인 구성
다음은 NGINX Plus용 SSO/Rest 플러그인의 샘플 서버 수준 구성 파일과 SSO/Rest 관련 지시문에 대한 설명입니다.
server {
listen 80 default_server;
server_name nginx.idfconnect.net;
underscores_in_headers on;
error_log /etc/nginx/log/debug.log debug;
# SSO/Rest Plug-In Configuration
SSORestEnabled on;
SSORestGatewayUrl https://www.idfconnect.net/ssorest3/service/gateway/evaluate;
SSORestPlug-InId nginxtest;
SSORestSecretKey ********;
SSORestUseServerNameAsDefault on;
SSORestSSOZone IDFC; # our session cookies are IDFCSESSION
SSORestIgnoreExt .txt .png .css .jpeg .jpg .gif;
SSORestIgnoreUrl /ignoreurl1.html /ignoreurl2.html;
}- SSORestEnabled – 플러그인을 활성화 또는 비활성화합니다. 비활성화하면 웹 앱은 더 이상 보호되지 않습니다.
- SSORestGatewayUrl – SSO/Rest 게이트웨이의 URL을 지정합니다.
- SSORestPlug-InId – 이 플러그인 인스턴스의 식별자입니다. 이 값은 SSO 관리자에게 제공됩니다.
- SSORestSecretKey – 플러그인의 비밀 키입니다. 이 값은 SSO 관리자에게 제공됩니다. 키 사용은 선택적입니다.
- SSORestUseServerNameAsDefault – 이 디렉티브를 사용하여 요청에 호스트 헤더가 없는 경우 서버 이름(NGINX server_name 지시문으로 지정)을 기본 호스트명으로 사용할지 여부를 지정합니다. 이 지시문은 프론트엔드 로드 밸런서나 네트워크 모니터가 HTTP_HOST 헤더 없이 NGINX에 폴링 요청을 보내는 경우 로그를 가득 채우는 경고 메시지를 방지하는 데 사용됩니다.
- SSORestSSOZone – 이 매개변수는 요청 쿠키를 지정된 접두사로 시작하는 게이트웨이에만 보내도록 플러그인에 지시합니다. 여러 존 접두사를 쉼표로 구분합니다.
- SSORestIgnoreExt – 플러그인이 무시하고 자동으로 승인하는 파일 확장명의 선택적인 공백으로 구분된 목록입니다.
- SSORestIgnoreUrl – 플러그인이 무시하고 자동으로 승인하는 선택적인 공백으로 구분된 URL 목록입니다.
3. SSO/Rest 플러그인 작동
해당 목차에서는 NGINX Plus와 함께 SSO/Rest Plug-In 을 정의하고, 이 플러그인과 NGINX Plus 서버로 보호되는 애플리케이션에 로그인하는 방법을 설명합니다.
샘플 웹 사이트는 LDAP 사용자 디렉토리를 지원하는 CA SSO (또는 “SiteMinder”)를 백엔드 액세스 매니저로 사용합니다.
NGINX 기본 구성 서버로 시작합니다.
다음으로 타 Access Control Agent와 마찬가지로 플러그인을 정의합니다.
첫 번째, 중요한 점은 Access Manager가 클라우드 기반인 NGINX Plus 서버를 다른 온프레미스 (On-Premiss) 웹 서버와 동일하게 인식한다는 것입니다.
두 번째로는 SSO/Rest가 Access Manager 자체가 될 수도 있고 기존 Access Manager와 함께 작동할 수 있다는 것입니다.
아래 예에서는 NGINX Plus가 테스트 앱 (testweb)의 출입문 역할을 한다는 것을 확인할 수 있습니다.
로그인 링크를 클릭하면 예상대로 NGINX Plus가 NGINX Plus에서도 제공되는 로그인 양식으로 Redirection 됩니다.
성공적으로 로그인 한 후, 우리는 플러그인이 주장한 헤더, 사용자 이름 및 사용자 세션에 대한 기타 속성을 볼 수 있습니다. 이를 통해 애플리케이션은 사용자의 신원 및 세션에 대한 기타 정보를 알 수 있습니다.
4. 강화, 보안, 단순
SSO/Rest는 기업이 Zero Trust WAM을 실현하는데 NGINX Plus의 가능성을 크게 향상시킵니다.
- 이를 통해 NGINX Plus는 모든 주요 엔터프라이즈 WAM 플랫폼과 함께 작동할 수 있으므로 NGINX Plus는 이러한 도구의 전체 보안 기능을 데이터 센터 외부의 시스템으로 확장하는 데 중심적인 역할을 할 수 있습니다.
- SSO/Rest는 웹 서버 앞에 있는 NGINX Plus 로드 밸런서를 조직의 인증 경계를 강화하기 위한 확실한 후보로 지정합니다.
SSO/Rest는 조직이 인프라를 크게 단순화할 수 있는 매력적인 옵션을 제공합니다. WAM 플랫폼과의 호환성을 유지하기 위해서만 레거시 웹 서버를 유지할 필요가 없으므로 이제 모든 것이 NGINX Plus가 될 수 있습니다. 로드 밸런서, 웹 서버 및 전면 인증 시행 지점으로 작동할 수 있는 단일 도구입니다.
5. Zero Trust WAM
제로 트러스트(Zero Trust) 보안 접근 방식은 Forrester Research의 John Kindervag가 2010년에 도입한 것입니다.
이 아키텍처에는 세 가지 중요한 원칙이 있습니다. 먼저, 어디에서든 안전하게 리소스에 액세스할 수 있도록 보장합니다. 요청자가 인증되었고 액세스 요청이 승인된 경우에만 리소스에 액세스할 수 있도록 허용합니다.
둘째, 최소 권한 원칙을 채택하고 엄격하게 액세스 제어를 시행합니다. 셋째, 모든 트래픽을 실시간으로 검사하고 로그를 유지하며 매 요청마다 지속적으로 재평가합니다.
WAM에서 Zero Trust란 다음을 의미합니다.
- 모든 요청은 앱에 도달하기 전에 검토되어야 합니다. 이는 모든 웹 기반 액세스 제어 솔루션이 측정되어야 하는 기준입니다. 인증된 사용자가 자원 – 파일, 페이지, 데이터, 도구 등 -에 액세스를 시도할 때, 해당 요청은 사용자의 권한과 비교됩니까? 사용자가 요청한 리소스를 볼 수 있는 권한이 있는지 확인됩니까? 그렇지 않으면 요청이 거부됩니까?
Zero Trust에서 요구되는 마이크로퍼리미터를 완전히 구현하려면 이 권한 프로세스의 실행을 앱 자체가 아닌 앞에서(즉, “프로그래밍 방식으로”) 수행해야 합니다.
이 중요한 요구사항의 직접적인 결과는 세션 기간과 타임아웃이 중앙에서 관리되어야 한다는 것입니다. 권한이 만료되면, 세션이 예정된 시간에 종료됩니까? - “최소 권한” 액세스 제어 정책을 엄격하게 시행하고 중앙에서 유지해야 합니다.
전통적으로는 Role Based Access Control (RBAC) 시스템을 사용했지만, 최신 액세스 제어 시스템에서는 보다 유연한 속성 기반 액세스 제어 (ABAC) 기술이 자주 사용됩니다.
사용되는 시스템에 상관없이, 액세스 제어 규칙의 정의와 유지 관리는 개별 애플리케이션에 분산되는 것이 아닌 중앙집중식으로 이루어져야 합니다. - 모든 인증, 액세스 요청 및 권한 부여는 중앙에서 로깅되어야 합니다. 이것은 두 가지 중요한 보안 메커니즘을 가능하게 합니다.
포괄적인 감사 및 리스크 분석입니다. 후자에서 각 액세스 요청은 리스크 점수가 지정되어 리스크 정책에 따라 적절한 액세스 제어 응답 (차단, 보다 강력한 인증 도전 등)이 결정됩니다.
6. Zero Trust WAM, 결론
본질적으로, Zero Trust WAM은 액세스 제어의 정의 및 로깅 구성 요소의 중앙 집중화를 요구하지만 선언적 구성 요소는 분산되어 있어야 합니다. 이 두 가지 상반된 동작을 조화시키는 근본적인 동기는 애플리케이션 기반 또는 프로그램 기반의 액세스 제어에 대한 의존성을 제거하는 것입니다.
Zero Trust WAM은 오늘날의 세상에서 요구되는 것입니다.
다행히도, 기업용 WAM 도구(CA Single Sign-On, Oracle Access Manager 및 IBM Tivoli Access Manager 등)는 수년간 현장 통합 애플리케이션을 위해 보장할 수 있었습니다.
그러나 이러한 WAM 도구는 대부분 구식 “레거시” 도구이며, 클라우드, 컨테이너화 등 현대 아키텍처의 주요 요구 사항을 충분히 지원하지 못하는 경우가 많습니다.
과제는 보호된 환경 깊숙한 곳에 없는 애플리케이션 및 자원을 포함하는 데 경계를 확장할 수 있는 능력에 있습니다.
댓글을 달려면 로그인해야 합니다.