VPC 원격 접속을 받아들이려면 거부 테스트가 필요하다

원격 접속의 승인은 예상 결과의 표이지, 작동하는 페이지의 스크린샷이 아니다. 각 그룹마다 무엇이 성공하고 무엇이 실패해야 하는지 적고, 통제된 시간 창에서 전용 테스트 ID로 둘 다 실행하라. 경계를 증명하는 것은 거부 쪽이며, 로그인 성공은 터널이 존재한다는 것만 증명한다. 이 모든 것은 이미 선택한 VPN 제품으로 작동한다.

테스트에는 별도의 계정을 사용하고, 테스트 ID가 실제 예외로 오인되지 않도록 표시하라.

경계를 예상 결과로 적어라

구성 요소가 아니라 역할, 즉 누가 어떤 서비스를, 어디서, 어떤 ID로 필요로 하는지에서 시작하라. 예시 VPC에서는 한 그룹이 HTTPS를 통한 스테이징을, 다른 그룹이 운영 데이터베이스를 필요로 하고, 더 작은 세 번째 그룹은 게이트웨이 자체를 관리한다. 각 행에는 예상 허용과 예상 거부를 적고, 작동하지 않아야 하는 인접 서비스와 인접 계정도 포함한다. 그 표가 승인 기준이며, 테스트를 실행하지 않는 사람도 검토할 수 있다.

데이터베이스 로그인은 네트워크 경로와 별도로 테스트하라. 접근 가능한 TCP 포트가 승인되지 않은 데이터베이스 계정을 성공하게 만들어서는 안 되고, VPN 구성원 자격이 클라우드 IAM 역할을 만들거나 관리 API 접근을 부여해서도 안 된다. 이것은 세 가지 독립적인 통제이며, 각각 독립적으로 실패한다.

경로는 권한이 아니다

경로는 길을 가능하게 할 뿐, 권한을 부여하지 않는다. 경로를 숨기는 것은 클라이언트가 언제든 자신의 경로를 추가할 수 있어 목적지에서 강제되는 제한의 약한 대체물이다. 판단하는 통제는 보안 그룹, 데이터베이스 부여, 그리고 애플리케이션 자체의 권한 부여로 남는다. 테스트가 예상 밖으로 성공하면, 클라이언트에 있기를 의도한 라우팅 표가 아니라 먼저 목적지의 정책을 보라.

거부 테스트가 서버 쪽을 겨냥하는 이유도 같은데, 그 결과는 클라이언트를 편집해 바꿀 수 없기 때문이다.

통제는 실제로 어느 출발지를 보는가?

통제가 평가하는 출발지 주소는 게이트웨이 아키텍처에 달려 있다. EC2에 호스팅된 게이트웨이는 라우팅된 풀을 전달하거나 자신의 주소로 변환하거나 NAT 이후 다른 주소를 제시할 수 있고, 관리형 Client VPN은 서브넷에 연결되어 자체 모델을 따른다. 보안 그룹과 네트워크 ACL은 그 처리 이후에 도착하는 것을 본다. 잘못된 출발지 가정으로 규칙을 검사하는 것은 올바르게 보이면서 잘못된 트래픽을 허용하는 경계를 만드는 흔한 방법이다.

각 결과를 ID와 세션, 리소스, 작업, 시각, 결정이라는 가장 작은 유용한 사건과 연결하라. CloudTrail API 호출, VPC 흐름 기록, VPN 세션 로그는 서로 다른 질문에 답하며, 어느 하나만으로는 애플리케이션 감사가 아니다.

ID를 폐기하고 다시 테스트하라

폐기도 같은 표에 포함하라. 테스트 ID를 제거해 새 세션이 거부되는지 확인한 뒤, 소유자가 다르고 동작도 다르므로 기존 세션의 처리 방식을 따로 확인하라. 게이트웨이를 재시작하거나 교체한 뒤 손으로 추가한 예외가 조용히 사라지거나 더 넓게 돌아오지 않는지 확인하라. 다음 배포까지만 유지되는 경계는 경계가 아니다.

이 중 어느 것도 패치, 복구, 자격 증명 수명 주기 작업을 대체하지 않는다. 더 좁은 약속을 측정 가능하게 만드는데, 적절한 사람이 적절한 서비스에 도달하고 인접한 경로와 계정과 관리 표면은 부여 밖에 남는다.

표를 배포와 함께 보관하고 게이트웨이가 바뀌면 다시 실행하라. 테스트는 싸지만 그 뒤의 가정은 싸지 않다.