임시 IP 허용 목록 링크: 그 허용이 실제로 통과시키는 것

클릭 한 번을 임시 방화벽 규칙으로 바꾸는 것은 편리하며, 동시에 누가 서비스에 도달할 수 있는지를 결정하는 권한 부여 체계를 세웁니다. 그것이 발급하는 것은 사람이 아니라 주소이고, 그 차이는 두 사람이 하나의 NAT를 공유하는 순간부터 중요해집니다. 허용의 범위를 한정하고, 의도적으로 확인하며, 링크가 만들어지기 전에 만료에 의미를 부여하십시오. 앞에 놓인 결정은 경계를 어디에 둘 것인가이며, 경계가 있어야 하는가가 아닙니다.

허용이 어떤 질문에 답하는지 결정하십시오

요구 사항에서 시작하십시오. 이름이 지정된 사람이 서비스에 도달해야 하고 애플리케이션이 이미 그 사람을 인증한다면, 인증된 게이트웨이는 집행 지점에서 신원을 유지하며 주소 허용이 전혀 필요하지 않습니다. 대상이 빌드 에이전트, 관리용 점프 포트, 또는 사용자 로그인에 참여할 수 없는 기기라면 범위가 제한된 주소 허용이 유일하게 실용적인 통제일 수 있습니다.

사용자 대상 애플리케이션에 주소 허용을 택하면 진짜 권한 부여 문제는 다른 곳으로 옮겨가고, 포털은 자기가 닫지 않은 틈에 대한 책임을 물려받습니다.

서버에서 요청을 제한하십시오

브라우저가 목적지, 포트, 접두사를 고르게 해서는 안 됩니다. 포털은 자체 기록에서 서비스를 찾고 서버 측 시험으로 권리를 확인하는데, 이는 OWASP의 권한 부여 지침 이 모든 요청에 적용하는 것과 같은 원칙입니다. 주소 도출도 보호된 경계에 속합니다. 역방향 프록시가 클라이언트 주소를 보고할 때는 설정된 프록시 체인과 그 문서화된 헤더 처리만 받아들이십시오. 방문자가 제공하는 전달 헤더는 출처에 관한 주장일 뿐 그 증거가 아닙니다.

그다음 포털과 서비스가 같은 출처를 보는지 확인하십시오. 분할 터널, 한 번의 프록시 홉, IPv4와 IPv6의 차이는 두 목적지에 서로 다른 주소를 줄 수 있으므로 한 경로에서 활성화한 허용이 다음 요청을 덮지 못할 수 있습니다.

설치하기 전에 허용을 보여 주십시오

링크를 열면 제안된 서비스, 관찰된 출처, 기간을 보여 주고 아직 아무것도 바꾸지 않아야 합니다. 그 한 단계가 이메일로 온 링크를 행동에서 제안으로 바꾸고, 미리보기 봇이나 메일 스캐너가 단지 가져오는 것만으로 접근을 허용하지 못하게 합니다.

확인은 일반적인 교차 사이트 및 출처 방어를 갖춘 상태 변경 요청이어야 합니다. 토큰은 일회용이어야 하고 규칙이 설치되는 순간 원자적으로 소비되어야 하며, 기록은 소유자, 서비스, 주소, 허용 식별자, 만료를 남기되 원시 토큰은 절대 기록하지 않아야 합니다.

토큰 전달에는 규칙 자체와 같은 주의가 필요합니다. 만료되었거나 이미 소비된 링크가 여전히 규칙을 만든다면 그것은 같은 열쇠로 설치된 두 번째 문입니다.

허용이 살아 있는 동안에도 주소는 공유됩니다

사무실 NAT, 통신사 NAT, 공유 VPN 출구는 각각 여러 사람을 하나의 주소 뒤에 둡니다. 그 주소를 허용하면 그 뒤에 있는 모두를 허용하는 것입니다 — 서비스의 다음 경계에 관한 한 —, 서비스가 기대하는 계정을 누가 가졌는지는 아무것도 증명하지 못합니다.

규칙을 제거하는 것도 보편적인 연결 해제는 아닙니다. 이미 성립된 연결, 캐시된 애플리케이션 토큰, 장시간 세션은 규칙보다 몇 분 또는 훨씬 오래 살아남을 수 있으므로, 고르는 수명은 규칙이 얼마나 존재하는지가 아니라 허용 이후 서비스가 무엇을 하는지를 반영해야 합니다.

네 가지 경우와 두 주소 체계를 시험하십시오

허용은 그것이 견디는 네 가지 경우만큼만 좋습니다. 새로 허용된 요청, 승인되지 않은 요청자, 같은 링크의 재생, 만료 후의 같은 요청입니다.

그다음 각 체계를 따로 시험하십시오. 서비스가 관찰하는 출처 주소가 둘 사이에서 다를 수 있기 때문입니다.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

유용한 결과는 정상적인 사용자 권한 부여 아래에 놓인 임시적이고 감사 가능한 허용 결정이며, 먼저 클릭한 사람의 이름을 달고 있는 영구적인 개방이 아닙니다.