AWS Client VPN 장치 상태 검사: 접속을 막기 전에 섀도 모드로 확인할 것

AWS Client VPN에 장치 상태 검사를 붙일 계획이라면, 새 정책을 바로 강제하기 전에 섀도 모드에서 누가 왜 막힐지 확인해 보세요. 장치 관리 도구의 상태 보고가 잘 들어오는지, 조건을 제대로 읽었는지, 그리고 이미 적용된 VPN 규칙은 무엇인지를 나누면 로그가 한결 읽기 쉬워집니다. 이 글은 기존 Client VPN을 운영하면서 관리 기기의 접속 기준을 추가하려는 팀을 위한 안내입니다.

이 기능의 첫 공개는 2026년 10월 5일입니다. 11월 5일 AWS가 후속 글을 내면서 정책을 바로 적용하기 부담스러운 팀을 위해 섀도 모드와 실제 로그에서 볼 필드를 구체적으로 설명했습니다. 아래 내용은 11월 8일 확인한 공식 자료를 바탕으로 합니다. 표의 팀과 상황은 판단 순서를 설명하기 위한 가상 사례이며, 실제 VPN 설정 변경이나 접속 차단 시험은 하지 않았습니다.

VPN에 로그인됐는데, 무엇을 더 확인하나요?

출장을 나간 팀원이 VPN 로그인에 성공했다고 해 볼게요. 계정 인증은 통과했지만 그 노트북이 회사 관리 대상인지, 보안 도구가 보고하는 기준을 만족하는지는 로그인 결과만으로 알기 어렵습니다. 장치 상태 검사는 이 두 번째 질문을 접속 결정에 반영하는 기능입니다. 회사가 이미 사용하는 장치 관리나 보안 제품이 내놓는 신호를 AWS Client VPN의 정책과 연결합니다.

장치 신뢰 공급자는 장치에 관한 정보를 서명한 토큰으로 제공합니다. Client VPN은 이 정보를 Cedar로 작성한 권한 부여 정책에 대입해 평가합니다. 예를 들어 정책이 특정 공급자의 관리 상태를 요구한다면, 그 값이 들어오는지가 출발점입니다. 관리 콘솔에 노트북이 보인다는 사실과 그 장치에서 접속할 때 필요한 속성이 실제로 넘어온다는 사실은 따로 확인해야 해요. 서비스가 물리적 장치를 따로 점검해 주는 과정으로 이해하면 기대와 결과가 달라집니다.

여기서 정책과 기존 권한 부여 규칙의 역할도 갈립니다. 새 정책은 그 연결이 트래픽을 보낼 수 있는지 판단합니다. 기존 규칙은 허용된 연결이 어느 네트워크 목적지에 갈 수 있는지 결정합니다. 장치 정책이 허용으로 나왔다고 서버나 모든 사설 대역에 접속할 수 있는 건 아닙니다. 반대로 기존 서버 접근 권한이 충분한 사용자도 장치 정책에서 거부되면 그 연결을 이용할 수 없습니다.

기존 Lambda 클라이언트 연결 핸들러를 쓰는 팀은 특히 이 구분이 필요합니다. AWS는 연결 시 새 정책과 기존 핸들러가 독립적으로 평가되며 둘 중 하나라도 연결을 거절할 수 있다고 설명합니다. 새 정책이 섀도 모드라고 기존 검사가 멈추지는 않습니다. 접속 문제를 접수할 때 사용자 인증, 장치 정책, 핸들러, 목적지 접근을 한 항목으로 묶지 않으면 담당자도 훨씬 빨리 찾을 수 있습니다.

확인할 층	운영자가 던질 질문
사용자 인증	먼저 계정과 인증 방식이 정상인가요?
장치 정책	어떤 공급자 토큰과 사용자 속성으로 판단했나요?
기존 연결 핸들러	새 정책과 별개로 거절한 기록이 있나요?
목적지 규칙	연결은 되는데 특정 주소나 서비스만 막히나요?

장치 목록부터 준비하면 정책 문장이 짧아집니다

정책을 쓰기 전에 사용하는 운영체제와 VPN 클라이언트, 장치 신뢰 공급자, 담당팀을 작은 표로 정리해 보세요. 문서에서 확인한 장치 상태 검사 전제는 Windows, macOS, Ubuntu의 AWS VPN Client 6.2.0 이상입니다. 세 운영체제를 같은 공급자가 모두 지원한다고 읽으면 곤란합니다. 공식 발표의 출시 기준으로 CrowdStrike는 Windows와 macOS, Jamf는 macOS, JumpCloud는 Windows, macOS, Ubuntu에 해당합니다. 팀의 실제 제품과 지원 조합은 현재 관리자 안내에서 따로 대조해야 합니다.

서로 다른 공급자의 속성을 한 뜻으로 쓰기도 어렵습니다. 후속 글에 나온 예에서 CrowdStrike는 수치 점수를, Jamf는 위험 등급과 그룹을, JumpCloud는 관리 여부를 제공합니다. 한 제품의 점수 기준을 다른 제품의 위험 등급에 그대로 옮겨 적을 근거는 없어요. 두 공급자를 함께 쓰는 회사라면 정책 초안의 각 조건 옆에 ‘이 값을 주는 제품’과 ‘값이 없을 때 예상 결과’를 써 두는 편이 좋습니다.

사용자 쪽에는 장치 상태 지시문이 포함된 새 VPN 구성 파일도 필요합니다. 공식 설명에 따르면 다른 OpenVPN 클라이언트도 연결을 시도할 수 있지만 장치 속성 없이 평가됩니다. 그 속성이 필수인 정책을 강제하면 거부될 수 있습니다. 출장용 구형 장비나 위탁 업무용 장비처럼 평소 접속 빈도가 낮은 집단도 살펴보세요. 오늘 접속한 노트북 몇 대에서 값이 확인됐다고 전체 장비가 준비됐다고 판단하기는 이릅니다.

가령 관리팀이 ‘회사 맥에서는 잘 됩니다’라고 보고해도, 그 한 줄에는 범위가 빠져 있습니다. 누구의 장비였는지보다 어떤 운영체제와 클라이언트 조합인지, 등록된 장치와 미등록 장치 중 무엇을 봤는지, 처음 접속과 유지 중 어느 순간을 봤는지가 필요합니다. 개인 이름과 장비 식별자를 글이나 공유 문서에 늘어놓을 필요는 없습니다. 시험용 장치나 내부에서 승인한 분류명만으로도 빠진 집단을 찾을 수 있습니다.

섀도 모드에서 세 가지 로그 결과를 읽는 순서

섀도 모드에서는 정책을 평가하고 결과를 남기되 그 정책의 결정은 강제하지 않습니다. 그래서 로그에 거부가 있고 사용자가 정상 접속한 사례가 함께 나타날 수 있어요. 이때 먼저 같은 이벤트의 shadow-mode 값을 봅니다. enabled라면 새 정책이 거부했을 상황을 보여주는 관찰 기록입니다. 전체 접속의 성공 여부는 이벤트에 찍힌 접속 결과와 다른 규칙의 기록까지 대조해야 합니다.

CloudWatch 연결 로그에서 확인할 묶음은 authorization-policy-evaluation입니다. AWS 문서는 이 안에 result, evaluation-type, shadow-mode를 설명합니다. connection-attempt는 연결할 때의 판단이고 periodic은 이미 연결된 세션을 다시 평가한 기록입니다. 같은 사용자가 하루에 여러 이벤트를 남길 수 있으니, 전체 평가 이벤트 수를 영향받을 사용자 수로 옮겨 적지 마세요. 접속 시도와 주기 평가의 집계도 따로 두는 편이 비교하기 쉽습니다.

결과	섀도 모드에서 살펴볼 것
permit	예상한 장비와 속성으로 허용됐나요?
deny	실제로 제한할 집단인가요, 준비가 덜 된 집단인가요?
error	토큰이나 사용자 속성의 누락을 먼저 확인하세요.
평가 기록 없음	허용으로 세지 말고 정책과 로그 설정을 확인하세요.

특히 deny와 error를 다른 칸에 적어 보세요. 가상의 사례로 회사 장비인데 관리 상태가 기준을 만족하지 못했다면 정책과 장치 관리 쪽을 함께 볼 문제입니다. 토큰이 아예 안 왔거나 정책이 기대한 SAML 또는 Active Directory 속성이 없다면 값이 넘어오는 경로부터 확인할 일입니다. 공식 연결 로그 문서는 속성이 없는 상황을 오류 예로 들며 섀도 모드를 끄면 이 경우에도 연결이 거부될 수 있다고 안내합니다.

원인을 좁히는 데 정책 평가 컨텍스트가 도움이 될 수 있습니다. 다만 공식 예시에서도 컨텍스트에는 접속 주소나 인증 주체에 관련된 값이 들어갈 수 있습니다. 현장에서는 필요한 항목과 접근 가능한 담당자, 보존 범위를 먼저 정하세요. 이슈 보고에는 오류 종류와 적용 조건을 요약해도 충분한 경우가 많습니다. 문서 예제의 로깅 설정을 그대로 복사해 사내 정보를 넓게 공유할 이유는 없습니다.

한 번 붙었던 연결도 평가 대상입니다

AWS 관리자 문서는 연결할 때와 연결이 유지되는 동안 약 5분 간격으로 장치 상태를 평가한다고 설명합니다. 따라서 아침에 허용된 연결이 오후에도 반드시 허용되는 건 아닙니다. 공급자가 새 상태를 보고하고 정책을 만족하지 못하면 강제 상태에서 연결이 끊길 수 있습니다. 이 설명은 실제 회사 노트북이 정확히 5분 뒤에 끊긴다는 시간 보장이 아닙니다. 토큰이 갱신되고 서비스가 평가하는 흐름을 말합니다.

토큰 갱신이 잠시 끊기는 경우도 생각해 볼 수 있습니다. 후속 글에서는 새 토큰이 도착하지 않을 때 이미 받은 속성을 최대 15분간 사용한 뒤 장치 속성을 빼고 정책을 다시 평가한다고 설명합니다. 이때 결과는 정책에 달려 있어요. 장치 속성이 꼭 필요한 정책과 사용자 속성만 보는 정책을 같은 장애 처리로 가정할 수 없습니다. 이 차이는 공급자 장애나 에이전트 정지 시 지원팀이 확인할 질문을 바꿉니다.

연결을 유지하는 사람의 업무는 처음 접속하는 사람과 다릅니다. 예를 들어 파일 전송이나 긴 원격 작업이 예정된 시간에 정책을 강제하면, 같은 거부라도 영향이 달라집니다. 섀도 모드 관찰표에는 ‘새 접속’과 ‘이미 접속 중’이라는 행을 따로 두고, 각각 예상과 달랐을 때 업무 담당자에게 어떻게 확인할지 적어 보세요. 실제 사내 업무를 끊어서 시험할 필요 없이 승인된 시험 범위에서 시나리오를 먼저 정할 수 있습니다.

언제 강제로 바꿀지, 숫자 하나로 결정하지 마세요

가령 섀도 모드에서 거부 12건이 나왔다고 가정해 봅시다. 같은 시험 장비의 반복 시도인지, 서로 다른 업무 집단의 첫 접속인지에 따라 다음 행동은 달라집니다. 계획에 없던 거부를 운영 시간대와 장치 조합별로 분류하고, 이유를 설명할 수 없는 오류는 남겨 두세요. ‘열두 건이니까 적다’처럼 분모나 관찰 조건 없이 결론을 내리지 않는 것이 핵심입니다. 이 숫자는 설명을 위한 가정입니다.

적용 결정을 하기 전에 변경 승인자와 VPN 운영자, 사용자 문의를 받을 지원팀이 같은 요약을 보게 하는 것도 좋습니다. 변경 전 정책과 섀도 설정을 어디에서 확인할지, 문제가 생기면 승인된 절차로 어떻게 이전 설정을 복원하거나 새 정책의 강제를 중단할지 기록해 두세요. VPN에 접속해야만 설정 담당자와 연락이 되는 구조라면, 그 연락 경로도 검토할 항목입니다. 보안 도구를 끄거나 정책을 우회하는 방식으로 문제를 덮으면 원래의 상태 검사 목적을 잃습니다.

관찰이 끝나지 않았다면 강제 시점을 미루고 무엇이 미확인인지 남겨도 됩니다. ‘장치 2종에서 허용 확인, 협력사 조합은 미확인, 오류는 구성 파일 배포 후 재평가’처럼 범위가 보이는 기록이 막연한 적용 완료보다 도움이 됩니다. 이런 기록은 다음 정책 변경 때에도 재사용할 수 있습니다. 조건을 바꾼 뒤에는 이전 관찰이 새 조건까지 증명한다고 보지 말고 같은 질문을 다시 확인하세요.

자주 나오는 질문

섀도 모드에서 허용이면, 곧바로 사내 앱에 들어갈 수 있나요? 장치 정책의 허용만 확인한 것입니다. 목적지 규칙과 애플리케이션 자체의 로그인은 별개의 단계입니다. VPN 자체의 역할과 자원별 접근을 비교하고 싶다면 VPN과 ZTNA를 비교한 글도 참고할 수 있습니다.

기존 Lambda 핸들러는 바로 빼도 되나요? 새 정책이 함께 동작한다는 설명만으로 제거를 결정할 수 없습니다. 기존 핸들러가 검사하는 조건과 새 정책의 신호가 같은지를 먼저 확인하세요. 기존 기록의 장치 상태 필드와 새 정책 평가 결과를 혼용하면, 어느 쪽을 바꿔야 할지 잘못 판단할 수 있습니다.

몇 시간 보면 충분할까요? 이 글에서는 시간을 고정하지 않습니다. 업무 시간과 접속 유형, 쓰는 운영체제와 배포 상태가 조직마다 다릅니다. 관찰 기간을 정할 때는 기간 자체보다 그 안에서 중요한 장치 조합과 연결 시나리오를 실제로 봤는지 확인하세요. 못 본 집단을 기록하면 다음 일정에서 무엇을 확인할지 선명해집니다.

확인한 공식 자료

2026년 11월 8일 10월 5일 출시 안내, 11월 5일 AWS 운영 해설, Client VPN 장치 상태 관리자 문서, 연결 로그 필드 설명을 확인했습니다. 실제 회사 장비의 준비 상태나 지역별 조건, 운영비를 이 글에서 확인한 것은 아닙니다.

장치 전제와 섀도 평가, 세션 중 변화, 강제 적용 판단을 나눈 자체 개념도입니다.