[ 운송 보안 ]

SMTP 전달을 중단하지 않고 TLSA 레코드 게시 및 순환

이전 연결을 제거하기 전에 사전 게시, 캐시 인식 중복, 차량 확인 및 복구 경계를 통해 고정 매개변수 TLSA 롤오버를 계획하세요.

EmailAuth 연구팀 제공 · 8분 읽기

[ 핵심사항 ]

  • 변경 사항이 키, 인증서, 트러스트 앵커 또는 TLSA 매개변수를 대체하는지 식별합니다.
  • 고정 매개변수 롤오버의 경우 배포 전에 최소 2개의 TTL을 통해 이전 연결과 새 연결을 미리 게시합니다.
  • 활성 서비스 및 롤백 종속성을 이해한 후에만 이전 연결을 폐기하십시오.
이 페이지에서

[ 테이크아웃 ]

확인된 중복을 중심으로 DNS 및 SMTP 운영자를 조정한 다음 저장된 인증서와 안전한 롤백을 혼동하지 않고 단계적으로 배포하고 폐기합니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

각 롤오버 단계 확인

성공적인 배포 작업이 모든 SMTP 인스턴스가 의도한 키를 제공한다는 것을 증명하지는 않습니다.

다음 단계

  1. 보안 기준 및 전체 TLSA 튜플을 캡처합니다.
  2. 확장된 세트를 사전 출판하고 타이밍을 기록합니다.
  3. 오래된 데이터를 폐기하기 전에 각 활성 인스턴스를 확인하세요.

CISO/SecOps

공개 증거를 주요 보관 장소와 별도로 보관하세요.

DNS 계획에는 개인 키가 아닌 연결이 필요합니다.

다음 단계

  1. 사용법 및 매개변수 변경 사항을 명시적으로 검토하세요.
  2. 게시된 각 조합에 대해 현재 일치하는 기록을 유지합니다.
  3. DNSSEC 검증을 독립된 게이트로 취급하십시오.

창립자 / 비기술자

유지 관리 의존도 조정

DNS 캐시와 시차적 서버 배포는 유지 관리 기간보다 오래 지속될 수 있습니다.

다음 단계

  1. 게시 및 SMTP 소유자를 모두 할당합니다.
  2. 정당한 중복 및 복구 계획을 승인합니다.
  3. 최종 퇴직 단계 전에 증거가 필요합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

인증서를 갱신할 때마다 3 1 1 기록이 변경됩니까?

아니요. 해당 연결은 공개 키를 선택하므로 동일한 키를 사용하여 갱신하면 공개 키가 보존됩니다. 자동화가 키를 재사용한다고 가정하기보다는 실제 키를 확인하세요.

RFC 7672

새로운 고정 매개변수 연관은 얼마나 일찍 게시되어야 합니까?

RFC 7671 새 체인을 배포하기 전에 이전 세트를 최소 2개 이상의 TTL 이상으로 확대하도록 지정합니다. 오버랩 중에 현재 연결을 유지합니다.

RFC 7671

TTL을 낮추면 이전에 캐시된 데이터가 즉시 단축될 수 있나요?

아니요. 이전 TTL에 따라 이미 캐시된 복사본에는 자체적인 타이밍 고려 사항이 필요합니다. 실제 게시 및 캐시 기록을 기록합니다.

RFC 1035

하나의 매개변수 조합으로 미래 데이터만 게시할 수 있나요?

게시자 지침에는 게시된 각 사용법/선택기/일치 유형 조합에 대해 현재 일치하는 연결이 필요합니다. 미래 또는 폐기된 레코드는 해당 조합에 대한 유일한 레코드일 수 없습니다.

RFC 7671

사용되지 않는 연결은 언제 제거할 수 있나요?

새 체인이 배포되고 검증된 후 이전 연결은 더 이상 활성 종속성을 설명하지 않습니다. 제거하기 전에 백업 및 롤백 요구 사항을 검토하세요.

RFC 7671

이전 인증서를 복원하면 항상 안전한 롤백이 되나요?

아니요. 일부 클라이언트에는 만료 후 캐시된 새로운 전용 TLSA 세트가 있을 수 있습니다. 서버를 되돌리기 전에 현재 게시된 데이터와 캐시 기록을 평가하세요.

RFC 7671

사용법이나 선택자를 변경할 때 동일한 시퀀스를 적용할 수 있나요?

그렇게 가정하지 마십시오. 매개변수 전환에는 고정 매개변수 키 롤오버와 별도로 해당 RFC 7671 지침 및 호환성 검토가 필요합니다.

RFC 7671

TLS-RPT 실패가 롤오버 성공을 증명하지 않습니까?

아니요. 보고는 선택 사항이며 집계 및 지연됩니다. 실제 차량에 대해 직접 승인된 보안 DNS 및 SMTP 증거를 보관합니다.

RFC 8460

[ 출처 ]

출처

  1. RFC 1035

    섹션 §3.2.1 형식 · §3.3.13 SOA RDATA 형식

  2. RFC 8460

    섹션 §3. 보고 정책 · §4.1 보고 시간 프레임 · §4.3 결과 유형 · §5.2 압축 · §5.3 이메일 전송 · §5.4 HTTPS 전송 · §5.5 배달 재시도 · §5.6 메타데이터 차이 · §7. 보안 고려 사항

  3. RFC 7672

    섹션 §2.1 DNS 고려 사항 · §2.2 TLS 검색 · §2.2.1 MX 확인 · §2.2.3 TLSA 레코드 조회 · §3.1 TLSA 인증서 사용 · §3.2 인증서 일치 · §4. 서버 키 관리

  4. RFC 7671

    섹션 §6. 서비스 공급자와 TLSA 게시자 동기화 · §7. TLSA 기본 도메인 및 CNAME · §8. TLSA 게시자 요구 사항 · §8.1 고정 TLSA 매개변수를 사용한 키 롤오버 · §8.3 새 TLSA 매개변수로 전환

  5. RFC 6698

    섹션 §2.1 TLSA RDATA 와이어 형식 · §3. TLSA 인증서 연결을 위한 도메인 이름

[ 어휘 ]

어휘

사전 출판
서비스를 전환하기 전에 현재 연결을 유지하면서 향후 키에 대한 연결을 게시합니다.

RFC 7671

연관 중복
필요한 현재 및 전환 키 자료를 지원하는 TLSA 세트입니다.

RFC 7671

고정 매개변수
키 롤오버 중에 인증서 사용, 선택기 및 일치 유형 조합이 변경되지 않습니다.

RFC 7671

롤백 경계
게시되고 캐시된 새 전용 데이터가 추가 조정 없이 안전하지 않은 이전 서버 키로 반환될 수 있는 지점입니다.

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료