안 SPF 공유 이메일 서비스에 포함하면 많은 고객이 사용하는 인프라를 승인할 수 있습니다. 이는 서비스가 설계되는 방식인 경우가 많지만 권한에 대해서는 명확한 설명이 필요합니다. SPF 도메인 정책과 비교하여 연결 호스트를 확인합니다. 광범위한 긍정 일치는 테넌트별 암호화 자격 증명이 아닙니다.
실질적인 질문은 공급자가 다른 고객이 귀하의 SMTP ID를 사용하여 전송하는 것을 방지하는지 여부와 정책이 실제로 필요한 인프라 권한만 부여하는지 여부입니다.
신뢰 관계 매핑
각 포함 또는 공유 IP 범위에 대해 서비스, 비즈니스 소유자, 지원되는 봉투 도메인 및 문서화된 공급자 설정을 기록합니다. 메일이 공급자 소유의 봉투 도메인을 사용하는지 아니면 사용자가 제어하는 사용자 정의 도메인을 사용하는지 확인하세요. 공급자가 실제 평가된 도메인을 소유한 경우 루트 도메인에 포함을 추가해도 해당 메시지의 SPF 결과에는 전혀 영향을 미치지 않을 수 있습니다.
도메인 확인 및 발신자 제어에 대한 공급자의 최신 설명서를 읽어보세요. 문서가 불분명한 경우 서비스 소유자 또는 제공업체 지원에 대한 질문을 식별하세요. 자신의 계정에서 테스트를 통과했다는 이유만으로 모든 테넌트가 격리되었다고 주장하지 마십시오.
IP 기반 결정의 한계 이해
RFC 7208 §11.4 공유 시스템을 통해 사용자가 다른 사용자의 신원을 주장할 수 있는 사용자 간 위조 위험에 대해 설명합니다. SPF 패스는 어떤 고객 계정이 메시지를 시작했는지 증명하지 않고도 연결 호스트가 평가된 도메인에 대해 승인되었음을 설정할 수 있습니다. 따라서 공급자 측 시행은 보안 경계의 일부입니다.
이는 모든 공유 서비스가 안전하지 않다는 의미는 아닙니다. 이는 인증 모델에 두 개의 계층이 있다는 의미입니다. DNS 인프라에 권한을 부여하고, 서비스는 고객이 해당 인프라에서 ID를 사용하는 방식을 제한해야 합니다. 한 계층에 대한 증거가 다른 계층에 대한 증거로 제시되어서는 안 됩니다.
지원되는 가장 좁은 구성을 선택하세요.
공급자가 전송 제품 및 지역에 대해 지원하는 정확한 포함 또는 도메인 구성을 선호하세요. 이러한 차이점은 문서화되어 있습니다. 더 좁은 범위의 유지 관리 정책을 사용할 수 있는 경우 공급업체의 전체 네트워크 할당을 추가하지 마십시오. 해당 설계를 안전하게 유지할 수 없다면 더 좁은 범위의 포함을 고안하거나 공급업체 관리 정책을 IP 스냅샷으로 대체하지 마세요.
전용 반환 경로 하위 도메인은 서비스의 SPF 정책을 다른 메일과 분리할 수 있습니다. 이는 소유권과 라이프사이클 관리를 향상시키지만, 공급자를 공유하는 고객 간의 고립을 그 자체로 증명하지는 않습니다. 다른 인증 및 계정 제어를 설계의 별도 부분으로 검토하세요.
두 구성을 주의 깊게 비교하세요.
예시: v=spf1 ip4:192.0.2.0/24 -all 평가된 ID에 대해 해당 문서 네트워크의 모든 IPv4 주소에 권한을 부여합니다. 정책 이름만 지정 ip4:192.0.2.10 하나의 주소를 승인합니다. 더 좁은 정책은 소스 세트를 줄이지만 공급자가 서비스에 대해 해당 주소를 실제로 보장하는 경우에만 유용합니다. 지원되지 않는 제한으로 인해 장애 조치 중에 합법적인 전달이 중단될 수 있습니다.
아래에 RFC 7208 §5.2, 포함은 참조된 정책을 평가합니다. 현재 확장은 관찰이지 영구 계약이 아닙니다. 공급자가 정책을 변경하면 변경될 수 있습니다. 오늘 해결된 주소를 최종 진실로 취급하기보다는 의존성과 소유권을 포착하세요.
다른 테넌트를 테스트하지 않고 검토
검증을 위해 자신의 승인된 계정과 통제된 수신자를 사용하십시오. 예상되는 ID를 확인하고 어떤 인프라가 통과하는지 기록하세요. 문서, 승인된 구성 증거 또는 명시적으로 승인된 보안 테스트를 통해 테넌트 제한 사항을 평가합니다. 이론적 우려를 보여주기 위해 다른 고객의 도메인을 가장하려고 시도하지 마십시오.
소유자가 없는 새로운 포함, 비정상적으로 광범위한 네트워크 범위 및 서비스를 모니터링합니다. 정책 검토에서는 재귀 평가 제한도 확인해야 합니다. 여러 공유 공급자가 각 포함이 개별적으로 합법적인 경우에도 리소스 문제를 일으킬 수 있기 때문입니다.
수락 결정을 명확하게 하세요.
부여된 인프라 권한, 공급자 측 ID 제어, 알려진 증거 격차 및 책임 소유자에 대한 간략한 기록을 유지하십시오. 공급자 또는 서비스 구성이 변경되면 검토 일정을 잡으세요. 공유 인프라를 수용하는 것은 합리적일 수 있지만 결정은 녹색 SPF 배지보다는 완전한 신뢰 모델에 따라 이루어져야 합니다.
다음 결정을 기록하세요
인프라 권한(실제 정책, 봉투 도메인 및 관찰된 소스)과 테넌트 제어(문서화된 확인/시행, 구성 증거 및 해결되지 않은 격차)라는 두 가지 증거 행을 사용합니다. 귀하의 성공적인 SPF 결과는 첫 번째 행만 채웁니다. 공급자가 더 좁은 주소를 보장하지 않는 경우 지원되지 않는 제한을 검증된 보안 개선으로 간주하지 마십시오. 테넌트 간 테스트 또는 공급자 변경이 수행되지 않았습니다.