Squid Basic 인증이 여전히 이전 암호를 허용하는 이유

Squid의 암호 파일을 바꿔도 이후의 모든 요청이 반드시 헬퍼를 다시 호출하는 것은 아닙니다. Basic 인증에서 Squid는 검증에 성공한 사용자 이름과 암호의 쌍을 캐시할 수 있습니다.

Squid 6.13에서 해당 검증을 유효하다고 간주하는 기간을 제어하는 설정은 credentialsttl입니다. 예를 들면 다음과 같습니다:

auth_param basic credentialsttl 5 minutes

이는 정책 값의 예시이며 모든 환경에 적용되는 권장 사항은 아닙니다. 허용 가능한 철회 지연과 인증 백엔드가 감당할 수 있는 부하를 기준으로 선택하세요.

세 가지 검사를 구분하기

먼저 활성 헬퍼가 사용하는 파일을 수정했는지 확인하세요. 사용하지 않는 파일을 올바르게 바꿔도 효과가 없습니다. 다음으로 헬퍼가 파일을 읽고 새 계정 정보를 검증할 수 있는지 확인하세요. 마지막으로 실행 중인 인스턴스를 통해 새 프록시 요청을 시험하세요. 여기에는 자격 증명 캐시와 접근 규칙도 적용됩니다.

헬퍼와 실행 중인 프록시를 따로 시험하세요. 헬퍼는 현재 백엔드가 허용하는 정보를 보여 주지만 Squid는 여전히 캐시된 검증 결과를 재사용할 수 있습니다. 자격 증명을 교체할 때는 새 정보가 작동하는지와 적용되는 검증 기간이 지난 뒤 이전 정보가 거부되는지를 모두 확인하세요.

이 동작을 조사할 때는 전용 시험 계정을 사용하세요. 요청, 클라이언트 출발지, 목적지를 동일하게 유지하고 공유하는 명령 출력에 실제 암호를 넣지 마세요.

파일 수정에만 의존하지 말고 철회를 계획하기

검증 유효 기간이 짧아지면 백엔드 작업이 늘어납니다. 바쁜 서비스 전체에서 기간을 줄이기 전에 헬퍼 용량을 고려하고 실제 백엔드로 동작을 확인하세요. 사용 중인 버전과 구성에서 확인되지 않았다면 설정을 다시 읽는 것으로 관련된 모든 인증 상태가 지워진다고 가정하지 마세요.

긴급히 접근을 차단해야 한다면 계정이나 출발지에 대한 명시적 접근 거부가 별도의 경계를 제공할 수 있습니다. 암호 파일에서 삭제하는 것에만 의존하지 말고 해당 경로에서 그 거부가 적용되는지 시험하세요.

이 설정은 Basic 검증 캐시를 설명합니다. 연결 지향 인증 방식에는 추가 상태가 있으므로 유추만으로 같은 철회 모델을 적용하면 안 됩니다.