스테이징은 프로덕션이 아니다: 자체 접근 경계를 부여하라

스테이징은 테스트 시스템처럼 보이지만, 그 환경에 복사된 프로덕션 데이터베이스와 살아 있는 메일 자격 증명, 결제 키가 있다는 것을 발견하는 순간 달라진다. 그 시점에서 탭의 라벨은 의미를 잃고, 진짜 질문은 이 배포가 어디까지 도달할 수 있고 누가 그것에 도달할 수 있느냐이다. 정문 VPN은 그 질문에 답하지 않는다. 시스템으로 들어가는 한 경로를 제한할 뿐, 시스템이 나가는 방향에서 무엇을 할 수 있는지는 말하지 않기 때문이다. 대상에서 시작해 바깥으로 나아가라.

URL이 아니라 대상에서 시작하라

세 가지 대상은 세 가지 다른 설계를 낳는다. 사설 엔지니어링 환경에는 신원과 경로가 필요하다. 고객 인수 테스트에는 고객을 대표하는 계정이 필요하다. 공개 데모에는 자체 통제를 갖춘 의도적 노출이 필요하다. 대상을 먼저 적어 두면 미리보기 URL이 조용히 영구가 되는 흔한 표류를 막는다. 검토의 나머지 전부가 그 답에 달려 있다.

아무도 대상을 지목할 수 없다면, 그것을 문서 공백이 아니라 첫 번째 발견으로 취급하라.

정문과 그 뒤의 표면을 걸어 보라

주어진 URL을 믿기 전에 이름을 확인하고, 그다음 관리 경로를 직접 요청하라.

dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/admin

추가 레코드는 CDN이나 VPN 진입점을 우회하는 직접 원본 주소를 드러내는 경우가 많고, 그러면 의도한 통제가 선택 사항이 된다. 리디렉션은 애플리케이션이 어디에 있다고 생각하는지 알려 주고, 예상치 못한 스킴이나 호스트 이름은 후속 조치가 필요하다. 그럴듯한 관리 경로를 탐색하면 페이지가 아니라 거부가 나와야 한다. 인증되지 않은 관리 경로에서 200이 나오는 것이 바로 이 검토 전체가 찾던 발견이다.

환경이 무엇을 보여 주는지가 아니라 무엇을 할 수 있는지 확인하라

로그인을 요구하는 페이지도 백엔드 권한을 함께 배포된다. 워크로드가 어떤 신원으로 실행되는지 묻고, 그에 연결된 정책을 읽어라.

aws sts get-caller-identity

그 호출은 환경이 실제로 사용하는 계정과 주체를 보고하며, 그것이 이후의 모든 권한 질문의 출발점이다. 거기서 그 신원이 메일을 보내고, 돈을 옮기고, 프로덕션 비밀을 읽고, 프로덕션 데이터를 쓸 수 있는지 확인하라. 공유 프로덕션 자격 증명은 범위가 좁은 스테이징 신원으로 바꾸고, 있는 경우 공급업체 샌드박스를 선호하라. 실제 카드에 청구할 수 있는 테스트 계정은 호스트 이름만 다른 프로덕션 시스템이다.

검토가 끝난 뒤에도 경계를 유지하라

환경은 한 번의 감사로 안전해지지 않는다. 인사 이동을 견디는 소유권으로 안전해진다. 누가 접근을 제거하고,테스트 데이터를 초기화하고, 배포를 퇴역시키는지 지정하고, 미리보기에는 누군가 갱신해야 하는 만료를 부여하라. 격리는 격리된 것을 유지 관리하는 동안에만 도움이 된다. 다음 릴리스 뒤에 같은 경로를 다시 확인하라. 기능 플래그나 새 통합이 바로 거부된 경로를 열린 경로로 만드는 방식이기 때문이다.

허용된 워크플로와 거부된 워크플로로 설계를 받아들여라. 둘 다 문서대로 동작하면 경계는 존재한다. 행복한 경로만 시험했다면 그것은 희망이다.