본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
봇과 에이전트가 요청에 암호로 서명하기 시작하면서, 웹 사이트 운영자가 서비스를 설정할 때 공개 키를 알아야 할 필요성이 커지고 있습니다. 잘 알려진 페처와 크롤러의 공개 키 자료를 찾을 수도 있겠지만, 그 다음 1,000이나 다음 1,000,000은 어떨까요? 그리고 공격자가 주장하는 당사자가 맞는지 확인하기 위해 공개 키 자료를 어떻게 찾습니까? 이 문제를 검색이라고 합니다.
저희는 이 문제를 Amazon Bedrock AgentCore, 즉 대규모로 유능한 에이전트를 구축, 배포, 운영할 수 있는 에이전트 기반 플랫폼으로서 AI 에이전트가 웹 사이트와 대규모로 상호 작용할 수 있도록 하는 빠르고 안전한 클라우드 기반 브라우저 런타임인 AgentCore Browser를 통해 문제를 공유하고 있습니다 . AgentCore 팀은 각 고객이 자체 요청에 쉽게 서명할 수 있도록 하여 Cloudflare와 기타 CDN 인프라 운영자가 AgentCore가 아닌 개별 에이전트의 에이전트 서명을 모놀리식으로 볼 수 있도록 하려고 합니다. (참고: 이 방법으로는 개별 사용자가 식별되지 않습니다.) 이를 위해 Cloudflare는 AgentCore 고객의 공개 키를 대규모로 수집하고 등록하는 방법이 필요했습니다.
이 블로그 게시물에서는 인터넷에서 봇과 에이전트를 쉽게 발견할 수 있는 방법으로 봇과 에이전트 레지스트리를 제안합니다. 또한 레지스트리 형식으로 Web 봇 Auth를 확장하는 방법도 간략하게 설명합니다. 누구나 작성할 수 있고 쉽게 가져올 수 있는 IP 목록과 마찬가지로, 레지스트리 형식 은 에이전트 키를 검색할 수 있는 URL 목록이며, 쉽게 작성하고 가져올 수 있습니다.
저희는 이러한 레지스트리가 웹 사이트 운영자가 신뢰할 수 있는 개방형 큐레이터 생태계를 육성하고 강화해야 한다고 생각합니다.
지난 5월, Cloudflare는 봇 및 에이전트 개발자가 인프라에서 발생하는 요청에 암호화된 방식으로 서명하는 방법을 설명하는 Web Bot Auth라는 프로토콜 제안을 소개했습니다.
이제 Vercel, Shopify, Visa까지 제안된 프로토콜이 여러 번 구현되었습니다. 이 방식은 이미 활발하게 논의되어 기여가 있었습니다. Web 봇 Auth는 IP 및 사용자 에이전트와 같이 취약한 식별 방식에서 더욱 신뢰할 수 있는 암호화된 인증 방식으로 나아가는 첫걸음을 내딛습니다. 그러나 IP 주소와 마찬가지로 암호화 키는 가명 형태의 ID입니다. 대형 CDN과 같은 규모와 범위 없이 웹사이트를 운영하는 경우 알려진 크롤러의 공개 키를 어떻게 찾을 수 있을까요?
첫 번째 프로토콜 제안은 봇 운영자가 키를 호스팅하는 HTTP 엔드포인트를 참조하는 새로 정의된 HTTP 헤더 서명-에이전트를 제공하는 것이었습니다. IP 주소와 마찬가지로 기본적으로는 모두 허용이 있지만, 특정 운영자가 너무 많은 요청을 하는 경우, 레이트 리미팅을 높이고, 운영자에게 문의하는 등의 조치를 취하는 것이 좋습니다.
다음은 Shopify 온라인 스토어의 예시입니다.
Signature-Agent: "https://shopify.com"
이러한 점을 고려할 때, 다음과 같은 문제가 발생합니다. Cloudflare에서는 고객이나 소규모 원본에 종속되지 않는 개방형 큐레이션 생태계를 조성하면서 어떻게 합리적인 기본값으로 고객이 허용하고 싶은 트래픽을 제어할 수 있도록 보장할 수 있을까요?
이러한 생태계는 IP 주소(예: avestel-bots-IP-lists) 및 robots.txt(예: ai-robots-txt)의 목록을 위해 존재합니다. 두 경우 모두 인터넷에서 표준 목록을 찾아 해당 IP의 트래픽을 허용하거나 허용하지 않도록 웹 사이트를 쉽게 구성할 수 있습니다. Nginx 또는 haproxy에 대한 직접 구성을 제공하며 이를 사용하여 Cloudflare 계정을 구성할 수 있습니다. 예를 들어, 아래와 같은 robots.txt를 가져올 수 있습니다.
User-agent: MyBadBot
Disallow: /
여기서 레지스트리 형식이 등장하며, 서명 에이전트 키를 가리키는 URL 목록을 제공합니다.
# AI Crawler
https://chatgpt.com/.well-known/http-message-signatures-directory
https://autorag.ai.cloudflare.com/.well-known/http-message-signatures-directory
# Test signature agent card
https://http-message-signatures-example.research.cloudflare.com/.well-known/http-message-signatures-directory
끝입니다. 레지스트리에는 알려진 모든 서명 에이전트의 목록, 학술 연구 에이전트, 검색 에이전트를 위해 선별된 목록 등이 포함될 수 있습니다.
누구나 이러한 목록을 유지 관리하고 호스팅할 수 있습니다. IP 또는 robots.txt list와 유사하게, 이러한 레지스트리는 모든 공개 파일 시스템에 호스팅할 수 있습니다. 즉, GitHub에 리포지토리를 만들거나, 파일을 Cloudflare R2에 저장하거나, 이메일 첨부 파일로 보낼 수 있습니다. Cloudflare는 이 레지스트리의 첫 번째 인스턴스 중 하나를 제공하여, 다른 사람들이 여기에 기여하거나 자신의 레지스트리를 구축할 때 참조할 수 있도록 하고자 합니다.
서명 에이전트를 아는 것은 훌륭하지만, 충분하지 않습니다. 예를 들어, Cloudflare 인프라의 요청이 갑자기 실패하거나 업스트림에서 예기치 않은 오류를 발생시키는 방식으로 형식이 변경되는 경우에 대비한, Cloudflare가 검증된 봇이 되려면 연락 메서드가 필요합니다. 사실 운영자의 이름, 연락 방법, 로고, 예상 크롤링 속도 등 원본이 알고 싶어 하는 정보가 많습니다.
따라서 Cloudflare에서는 레지스트리 형식을 보완하기 위해 추가 메타데이터로 JWKS 디렉터리(RFC 7517)를 확장하는 서명-에이전트 카드 형식을 제안했습니다. 이 카드는 구식 연락처 카드와 유사하게 누군가가 에이전트 또는 크롤러에 대해 알고 싶어할 수 있는 중요 정보를 모두 포함하고 있습니다.
아래에 예시를 제공하겠습니다. jwks-uri를 도입하고, 보다 설명적인 로고를 추가하는 등 필드는 변경될 수 있습니다.
{
"client_name": "Example Bot",
"client_uri": "https://example.com/bot/about.html",
"logo_uri": "https://example.com/",
"contacts": ["mailto:bot-support@example.com"],
"expected-user-agent": "Mozilla/5.0 ExampleBot",
"rfc9309-product-token": "ExampleBot",
"rfc9309-compliance": ["User-Agent", "Allow", "Disallow", "Content-Usage"],
"trigger": "fetcher",
"purpose": "tdm",
"targeted-content": "Cat pictures",
"rate-control": "429",
"rate-expectation": "avg=10rps;max=100rps",
"known-urls": ["/", "/robots.txt", "*.png"],
"keys": [{
"kty": "OKP",
"crv": "Ed25519",
"kid": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
"x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs",
"use": "sig",
"nbf": 1712793600,
"exp": 1715385600
}]
}
Amazon Bedrock AgentCore는 대규모 AI 에이전트 구축 및 배포를 위한 에이전트 기반 플랫폼으로, AgentCore Browser 서비스에 웹 봇 인증을 채택했습니다(자세한 내용은 게시물에서 확인하세요). AgentCore Browser는 현재 공개 미리 보기로 제공되는 서비스 서명 키에서 프로토콜이 성숙되면 고객별 키로 전환할 계획입니다. Cloudflare 및 기타 원본 보호 서비스 사업자들은 AgentCore 전체가 아닌 개별 AgentCore 고객의 서명을 확인하고 검증할 수 있게 됩니다.
또한 Cloudflare는 Radar를 통해 제공하는, 신뢰하는 봇 및 에이전트용 레지스트리를 제공합니다. 이 공격은 레지스트리 형식 을 사용하여 여러분의 서버에서 Cloudflare가 신뢰하는 봇을 사용할 수 있도록 합니다.
이 레지스트리는 지금 바로 사용할 수 있습니다. Cloudflare는 Caddy의 Go 서버 서버에서 여러 레지스트리에서 키를 가져올 수 있는 데모를 제공했습니다. 이 이메일은 cloudflare/web-봇-auth에 있습니다. 구성은 다음과 같습니다.
:8080 {
route {
# httpsig middleware is used here
httpsig {
registry "http://localhost:8787/test-registry.txt"
# You can specify multiple registries. All tags will be checked independantly
registry "http://example.test/another-registry.txt"
}
# Responds if signature is valid
handle {
respond "Signature verification succeeded!" 200
}
}
}
서명 에이전트 카드 형식을 활용하여 레지스트리를 운영하고 큐레이션하려는 이유는 몇 가지가 있습니다.
들어오는 서명-에이전트를모니터링합니다. 이를 통해 도메인에 접근하는 에이전트의 서명-에이전트 카드를 수집할 수 있습니다.
기존 레지스트리에서 해당 오류를 가져와 직접 범주화하세요. 위의 모니터링 단계를 통해 구성된 일반 레지스트리가 있을 수 있지만, 범주가 더 많은 레지스트리가 더 유용할 수 있습니다.
상담원과 직접적인 관계를 수립하세요. 예를 들어 Cloudflare는 봇 레지스트리 에 이 작업을 수행하고, 여러분은 이슈를 제기할 수 있는 공개 GitHub 리포지터리를 사용할 수 있습니다.
사용자에게서 배우세요. 귀사에서 보안 서비스를 제공하는 경우, 고객이 통과할 레지스트리/서명 에이전트를 지정하도록 허용하면 귀중한 인사이트를 얻을 수 있습니다.
봇 및 에이전트를 위한 암호화 인증이 증가함에 따라 검색의 필요성도 증가합니다.
메타데이터를 서명-에이전트에 연결하고 이를 레지스트리 형태로 큐레이션하는 간단한 형식 및 사양을 도입하여 이러한 요구 사항을 해결하기 시작했습니다. HTTP 메시지 서명 디렉터리 형식은 자체 인증된 메타데이터를 포함하도록 확장되고 있으며, 레지스트리는 큐레이션 생태계를 유지합니다.
궁극적으로 클라이언트와 원본은 신뢰할 수 있는 서명 에이전트를 선택하고, 공통 형식을 사용하여 CDN 공급자 간에 구성을 마이그레이션하며, 큐레이션을 위해 타사 레지스트리에 의존하게 될 것입니다. Cloudflare에서는 이러한 기능을 봇 관리 및 규칙 엔진에 통합하기 위해 노력하고 있습니다.
체험을 원한다면 데모가 GitHub에 있습니다. 도움을 원하신다면 내년 한 해 동안1,111명의 인턴을 채용할 예정입니다.