온보딩을 기록 생성기가 아닌 증거 추적으로 만드세요.
승인된 비즈니스 서비스는 자동으로 승인된 도메인 구성이 아닙니다. 팀은 어떤 테넌트, 보낸 사람 신원, DNS 변경 및 데이터 공유 대상이 적절한지에 대한 결정이 필요한 동시에 이메일 플랫폼을 사용할 수 있는 권한을 가질 수 있습니다. 에이전트는 해당 작업을 구성하고 누락된 전제 조건을 노출하며 정확한 변경 제안을 준비할 수 있습니다. 친숙한 공급자 이름을 프로덕션 수정 권한으로 전환해서는 안 됩니다.
이는 제안된 작업 흐름입니다. EmailAuth 현재 서비스 검색, 승인 시행, 공급자 커넥터 또는 자동 확인을 구현한다고 주장하지 않습니다. 이러한 기능에는 최신 제품 증거가 필요합니다. 이 문서에서는 서비스 계정, DNS 영역, 메시지 스트림 또는 승인 제어가 검사되거나 변경되지 않았습니다.
비즈니스 서비스 및 책임 있는 소유자 식별
비즈니스 목적, 담당 팀, 승인된 제공업체 계정 및 의도한 메시지 카테고리부터 시작하세요. 서비스가 사용할 수 있는 도메인 또는 하위 도메인, 예상 수신자 모집단 및 해당 범위를 승인할 수 있는 사람을 기록합니다. 공급자의 인프라는 많은 고객이 공유할 수 있습니다. 보고서에 표시된 IP 또는 호스트 이름은 조사의 단서일 뿐 이 조직이 보낸 사람을 승인했다는 증거는 아닙니다.
에이전트는 승인된 인벤토리를 사용 가능한 관찰과 비교하고 가능한 일치 항목에 레이블을 지정할 수 있습니다. 소유자는 실제 서비스 인스턴스에 대한 모호성을 해결해야 합니다. 일치의 증거를 신뢰도 점수와 별도로 보관하세요. RFC 9990 집계 보고서 유용한 인증 및 출처 정보를 제공하지만, 그 내용은 허위일 수 있으며 독립적으로 상업적 관계를 구축하지 않습니다. RFC 9990 , 섹션 3.1 및 8.2.
액세스 확장 없이 필수 구성 요소 수집
해당 서비스 인스턴스에 대해 공급자가 현재 지원하는 설정 지침, 조직의 발신자 요구 사항 및 관련 기존 구성을 수집합니다. 기존 인증으로 읽을 수 있는 부분과 관리자가 필요한 부분을 식별합니다. 인벤토리를 준비할 때 상담원의 대화나 보고서에 비밀번호나 개인 키를 수집할 필요는 없습니다.
제안된 액세스 경계는 에이전트가 작업에 필요한 승인된 테넌트와 리소스만 검사할 수 있도록 허용해야 합니다. 광범위한 쓰기 권한이 있는 통합은 단지 프롬프트에서 분석을 요청하기 때문에 읽기 전용으로 설정되지 않습니다. OWASP의 과도한 기관 지침에서는 도구 기능과 다운스트림 권한을 모두 제한할 것을 권장합니다. 프로덕션에서 커넥터를 사용하기 전에 실제 적용을 확인하십시오. OWASP 과도한 대행사.
ID 및 변경 사항을 함께 미리보기
제안서는 눈에 보이는 작성자 도메인을 연결해야 합니다. SPF 신원, DKIM 도메인 및 공급자 계정에 서명합니다. 생성된 TXT 값은 해당 관계의 한 부분일 뿐입니다. DMARC 자격을 갖춘 인증된 식별자를 평가하고 조정 작성자 도메인과 함께; 공급자의 관련 없는 기본 서명은 자동으로 정렬되지 않습니다. RFC 9989 , 섹션 4.4.
관찰된 현재 상태와 함께 정확한 제안된 소유자 이름, 레코드 유형 및 값을 표시합니다. 변경이 좁은 범위의 레코드를 추가하는지, 기존 보낸 사람 권한을 변경하는지, 공급자 관리 이름을 통해 제어를 위임하는지 설명합니다. 전체를 자동으로 교체하지 마십시오. SPF 레코드, 도메인 위임을 확대하거나 다른 발신자의 위임을 제거하세요. 선택자 새로운 서비스를 적합하게 만들기 위해. 각 작업에는 책임 있는 승인자와 복구 결정이 필요합니다.
기술 전달과 별도로 보고 동의를 유지하세요.
온보딩에서 외부 집계 보고서 대상을 제안하는 경우 보고서를 받을 사람과 그 이유를 식별합니다. RFC 9990 외부 보고 방식에 대한 DNS 기반 확인을 정의합니다. 해당 기술적 확인은 프로토콜에 따라 보고서를 수신하려는 목적지의 의지를 확립합니다. 이는 해당 처리자와 보고 데이터를 공유하는 조직의 승인을 대체하지 않습니다. RFC 9990 , 섹션 4.
공급자 액세스에도 동일한 구별이 적용됩니다. 에이전트는 누군가가 권한을 부여하기 전에 필요한 관리 권한을 설명해야 합니다. 문서 준비 승인은 지속적인 계정 액세스, 자격 증명 생성 또는 테넌트 간 변경을 승인하지 않습니다. 지원되는 워크플로에 에이전트가 보유한 것보다 더 많은 권한이 필요한 경우 실행 단계가 권한 있는 관리자에게 할당된 상태로 유지되는 동안 준비가 유용하게 유지됩니다.
승인을 실제 제안에 바인딩
유용한 승인은 서비스 인스턴스, 테넌트, 도메인, 정확한 변경 사항 및 관련 현재 상태 스냅샷을 식별합니다. 실행 전에 해당 사실이 변경된 경우 기존 승인을 일반 라이선스로 처리하는 대신 검토를 위해 영향을 받은 변경 사항을 반환하세요. 실행 메커니즘은 모델 설명과 별도로 승인하는 행위자의 권한과 요청된 범위를 확인해야 합니다. OWASP 인증 치트 시트.
notices.example 사용하는 가상의 영수증 서비스를 생각해 보세요. 비즈니스 소유자는 고객 영수증을 승인하고, DNS 관리자는 제안된 공급자별 선택기를 검토합니다. 해당 승인에는 다른 테넌트 추가, 보고서를 대행사로 리디렉션 또는 상위 도메인의 DMARC 정책 변경이 포함되지 않습니다. 이 예에는 실제 공급자 값이 포함되어 있지 않으며 승인 제어가 존재하거나 작동한다는 것을 보여주지 않습니다.
인계하기 전에 실제 메시지를 확인하세요.
계획된 승인 테스트에는 DNS 검사기뿐만 아니라 승인된 수신자와 실제 서비스의 메시지를 사용해야 합니다. 발신자 신원, 선택된 서명, 신뢰할 수 있는 수신자가 추가한 인증 결과 및 관찰된 배달 성향을 캡처합니다. 인증 증거는 메시지와 함께 제공된 유리한 헤더에서 가져오는 것이 아니라 수신자의 신뢰 경계 내에서 해석되어야 합니다. RFC 8601 , 섹션 7.
최종 SMTP 수락은 받은 편지함 배치 또는 성공적인 비즈니스 처리에 대한 증거가 아닌 전송 전달입니다. 결과를 별도로 보관하세요. 핸드오버는 구성 소유자, 보유 증거, 변경 종속성, 모니터링 책임 및 승인된 복구 경로를 식별해야 합니다. 해결되지 않은 정렬 결과는 명시된 승인 기준을 방해하는 것이며 DNS 값이 저장되었기 때문에 완료를 선언하는 이유가 아닙니다. RFC 5321 , 섹션 4.2.5.
시운전 증거가 여전히 필요함
전제 조건 확인, 변경 미리보기, 검증 및 인계를 통해 승인된 하나의 서비스를 실행합니다. 이 정확한 요구 사항은 여전히 열려 있습니다. 작업 흐름과 지도는 다큐멘터리 준비입니다. 온보딩이 입증되었다고 주장하기 전에 실제 서비스 ID, 현재 공급자 적용 가능성, 승인 시행, 실행된 변경, 실제 메시지 결과 및 인계 증거를 수집해야 합니다.