DanzzaN

보호된 Vault 시험 배포 구성

2026-09-05 범위 변경: 아래는 과거 시험·구현 기록이다. 현재 실행은 원격 Vault 재설계와 선행 검증의 로컬 stdio/SSH 계획을 따른다. 웹·Android와 Auth0 후속 시험은 재개하지 않는다. AWS 시험 리소스는 사용자 요청으로 보존한다. Auth0 정리 상태는 HANDOFF에서 확인한다.

2026-09-05 재설계: 현재 구조·선행 검증·다음 행동은 원격 Vault 재설계와 선행 검증를 따른다. 아래 3R/Auth0 관련 순서는 이전 검토 이력이며 현재 착수 지시가 아니다. Auth0 구현과 별도 차단 DB는 보류했다.

3R-3a를 승인 후 실행했고 실제 Cognito discovery의 S256 광고 부재로 중지했다. 이번에 만든 pool·resource server·domain은 삭제 후 부재를 확인했다. 3R-3b에서 Auth0 우선 후보·차단 상태 보완안을 준비했다. 다음은 3R-3c Auth0 로컬 인증 구성 준비다. 아래 로컬 준비 내용은 3R-2b 기록이다. 전체 목표와 후속 순서는 원격 Vault 전환 실행계획, T1~T6은 Vault 직접 읽기 최소 시험안에 둔다.

준비한 실행물

실행 순서·실패 처리·사용자 로그인·클라이언트 격리의 상세는 배포 실행 설명에 있다. 모든 파일은 로컬 임시 자료이며 실제 Vault 업로드 대상이 아니다.

실행물맡기는 일
GitHub 읽기 어댑터고정 비공개 저장소·commit·tree mode·blob SHA/크기 확인, GET만 사용. 404 commit과 저장소 접근 실패 구분
보호된 읽기 전송기존 Cognito 검증 사용, read scope·출처·본문 한도·만료 확인, 읽기 도구 3개만 노출. 로그는 반환 경로·commit·도구·시간만 기록
배포 입력 생성pool·역할·정책 기본 입력, 실제 pool ID 뒤 해당 ARN 정책, 실제 callback 뒤 client 입력 생성. 미확정 값을 지어내지 않음
배포기본 무실행. Apply 때 계정·기존 리소스·provider gate 확인, 코드 hash 검증, 실제 URL 설정 후 공개. 읽기/marker를 분리
활성화callback 확인용 discovery 상태에서 실제 subject/client 설정으로 전환. 기존 receipt·hash·역할·scope·callback 대조
정리소유 receipt를 대조한 함수 URL·함수·로그만 삭제/부재 확인. 나머지 Cognito·SSM·토큰·역할·앱 정리는 실행 설명에서 별도 추적

읽기·marker 번들을 따로 빌드했다. marker wrapper는 기존 handler.mjs·store.mjs·auth.mjs를 변경하지 않고 활성 모드에서 기존 구현을 호출한다. 읽기 모듈의 도구별 OAuth metadata를 보강했다. 각 함수의 discovery 모드는 실제 인증 메타데이터만 공개하고 모든 토큰을 거부하며 SSM이나 GitHub를 읽지 않는다. ChatGPT 관리 화면에서 callback을 얻기 위해 먼저 URL이 필요한 경우에 사용한다.

승인 대상으로 준비한 범위

고정 AWS 계정은 886682668993, 리전은 ap-northeast-2, 실행 전용 사용자·프로필은 vault-preflight다. 이 표의 합성 시험 범위는 사용자가 승인했다. 승인과 실제 생성은 구분하며, 실행 결과는 아래 3R-3a 기록을 따른다.

대상제안 범위·책임
비공개 GitHubDanzzaN-il/vault-protected-preflight-20260905 1개. F01~F12, 고정 marker 2개와 .probe/ 상태/영수증만. 실제 Vault·코드·manifest·판정표 제외
Cognitovault-protected-preflight-20260905 Lite pool 1개, classic domain vault-protected-886682668993-20260905, 관리자 생성 사용자 1명, vault-probe resource server, ChatGPT/Claude × read/marker의 public code client 최대 4개
읽기 Lambda·역할vault-protected-preflight-mcp / vault-protected-read-runtime. 읽기 도구만 제공하며 GitHub 읽기 token·cursor key 외 SSM 접근 없음
marker Lambda·역할vault-preflight-mcp / vault-protected-write-runtime. 기존 두-marker와 20회 쓰기 한도 유지. 기존 함수가 있으면 덮어쓰지 않음
SSMStandard SecureString 3개: /vault-protected-preflight/github-read-token, /vault-protected-preflight/cursor-key, /vault-preflight/github-token. 기본 alias/aws/ssm 사용. 기존 값 존재 여부부터 확인하고 무조건 덮어쓰지 않음
로그·동시성함수별 로그 그룹 1개, 보존 1일. 256MiB ARM, timeout 45초, 예약 동시성 1 기본. 할당 거절 시 공개 전 중지하며 공용 동시성으로 자동 전환하지 않음
작업자 권한함수/로그 2개와 역할 2개의 PassRole만 제한한 기본 정책. 실제 pool 생성 뒤 그 ARN에 제한한 관리 정책 추가. IAM·SSM·pool 최초 생성은 권한 있는 관리자 단계로 분리

NAT·VPC·DynamoDB·S3 배포 버킷·유료 사용자 지정 KMS 키·SMS·M2M grant·구독 변경은 이 안에 없다. 기존 vault-preflight-runtime과 전용 IAM 사용자는 보존한다. GitHub PAT는 읽기/쓰기 각각 지정 저장소의 Contents 권한으로 제한하며, 현재 호스트 gh의 넓은 인증 토큰을 서버에 넣지 않는다.

이 단계의 승인은 위 시험 리소스와 합성 자료에만 해당하도록 받는다. 실제 Vault 이전, 기존 스킬 감축, 영구 운영 전환은 후속 별도 범위다. GitHub 합성 저장소는 PAT 회수 뒤 검증 증거로 비공개 보존하며, 저장소 삭제는 별도 요청 때 수행한다.

비용과 정지 조건

2026-09-05 AWS 공식 서울 리전 가격표를 읽어 추출 가격 자료에 원천 URL·발행 시각·단가를 남겼다. 아래 계산은 가정한 사용량의 예산 추정이며 실제 사용량·청구액이나 과금 상한이 아니다.

  • 서울 ARM Lambda 첫 구간은 GB-second당 $0.0000133334, 요청당 $0.0000002다. 두 함수를 합쳐 1,000호출·각 256MiB·평균 1초라면 약 $0.00353; 모든 호출이 45초를 썼다는 계산은 약 $0.15020다. 무료 구간은 계산에서 빼지 않았다. 공식 서울 Lambda 가격표
  • Cognito Lite 서울 첫 유료 구간은 1 MAU당 $0.0055다. 1명으로 시험하며 무료 구간의 계정 공유 사용량을 확인하기 전에는 무료라고 단정하지 않는다. 공식 서울 Cognito 가격표
  • Standard Parameter Store 자체 요금과 KMS 호출·로그·전송 요금은 분리한다. 이번 짧은 합성 시험의 **운영 목표 예산은 총 1 미만**으로 제안하고, 원래 월 20 목표의 영구 운영 견적으로 확대하지 않는다. 기타 항목의 실제 사용량·청구는 시험 뒤 확인한다. SSM 요금, KMS 요금, CloudWatch 요금

공개 Function URL은 인증 실패·만료 응답도 Lambda 호출을 유발한다. 2시간 애플리케이션 만료와 비용 알림은 과금 차단이 아니다. 실행 담당자가 시험을 지켜보며 끝난 뒤 URL 제거·동시성 0·함수 삭제를 수행한다. 자동 예약 종료는 만들지 않았다. 예상하지 않은 호출이나 실패 반복이 보이면 URL을 먼저 닫고 원인을 확인한다. 예약 동시성 1을 확보할 수 없으면 중지하고, 상한 없는 AccountShared 대안의 비용 위험과 새 실행 범위를 사용자에게 따로 제시한다.

인증·클라이언트 준비

OpenAI의 공식 요구에 따라 실제 issuer discovery의 S256 광고, code flow, HTTPS endpoints를 check-provider.mjs로 확인한다. Cognito가 PKCE 기능을 지원한다는 문서만으로 metadata gate를 통과시키지 않는다. 후속 실제 pool 검사에서 S256 광고 부재로 실패했다. 해당 pool은 정리했다. 토큰 aud는 접속한 함수의 실제 /mcp URL과 일치해야 한다. 두 함수의 audience를 서로 대신 쓰지 않는다. OpenAI MCP 인증, Cognito resource binding

ChatGPT callback은 각 앱 관리 화면에 표시된 정확한 URI를 사용한다. Claude Code는 실제 환경에서 고정 localhost callback port와 client ID 지원을 확인한 뒤 등록한다. public client·code flow·token revocation·scope를 서버 배포 시 다시 대조한다. 토큰 서명만 검사하지 않고 매 요청 Cognito GetUser로 회수 상태를 확인하는 기존 코드를 재사용한다. Claude MCP 인증, Cognito 회수

API로 만든 Cognito app client에는 hosted login에 필요한 branding 적용도 포함한다. 이 구성은 classic domain version 1과 UI customization을 사용하도록 준비했으며 실제 로그인 화면 성공은 별도 확인한다. CreateUserPoolClient, SetUICustomization

사용자는 비밀번호 설정과 OAuth 로그인·필요 시 MFA를 직접 수행한다. 대화·Vault·쉘 인자·로그로 비밀번호나 PAT를 전달받지 않는다. 관리자가 실제 pool/user/client 식별자를 만들고 비밀이 아닌 설정값을 준비하면, 실행 코드는 그 설정을 사용한다.

이 Windows 작업에서는 claude 명령과 확인한 일반 실행 경로에서 CLI를 찾지 못했다. 설치·설정 변경은 하지 않았다. 선택할 Claude Code 실행 환경의 버전·--help·/context·/mcp 확인이 남아 있다. 공식 CLI의 --tools ""는 built-in 도구를 제외하면서 MCP를 유지할 수 있고, --disable-slash-commands와 별도 설정 디렉터리는 격리 후보다. 실제 버전에서 이를 확인한 뒤 시험에 사용한다. --bare는 CLAUDE.md도 건너뛰므로 기존 지속 진입점 시험의 대체 성공으로 쓰지 않는다. Claude CLI, 설정 위치

ChatGPT Work도 새 프로젝트·대화라는 사실만으로 개인 스킬·기억의 제외를 확정하지 않는다. 해당 환경에서 실제 전달된 지침·연결·기억 범위를 확인하지 못하면 환경 판정은 판정 불가다. 답을 포함한 fixture 생성 코드·판정표를 실행 모델이 로컬로 읽지 못하도록 하고, 최초 공통 진입 지침만 제공한다.

3R-2b 당시 확인과 미검증

  • 호스트 gh auth status: DanzzaN-il 정상. 샌드박스 keyring 실패 뒤 정확한 호스트 명령으로 구분했다. 예정 GitHub 저장소 조회는 404였고 생성하지 않았다.
  • aws sts get-caller-identity: 계정·전용 사용자 일치. 기존 vault-preflight-runtime 역할은 조회됐다. 새 읽기 함수 vault-protected-preflight-mcp의 GetFunction은 AccessDenied여서 존재 여부는 미확정이다. 권한 거부를 부재로 기록하지 않는다.
  • node deployment/build.mjs: 읽기·marker wrapper 번들 빌드 성공. node --test reading/reading.test.mjs reading/deployment.test.mjs protected.test.mjs: 53 통과, 실패·skip 0. 읽기 20, 신규 원격 어댑터/전송/번들 10, 기존 marker 23이다. 현재 로그
  • Python 입력 검사 5 통과, PowerShell 무실행/거부/문법 검사 5 통과. AWS CLI 2.35.24 skeleton과 입력 필드 대조는 AWS 수용 검증이 아니다. Python 초기 시험은 sandbox 임시 폴더 권한 오류였고 시험 산출 위치를 명시해 재실행했다. PowerShell 초기 시험은 stub의 script scope 때문에 호출 계측이 틀려 계측 범위를 명시한 뒤 통과했다.
  • 미검증: 실제 IAM 권한 수용·SSM/KMS·GitHub API·Cognito discovery/로그인/회수·배포/정리 명령의 AWS 성공·두 클라이언트의 환경과 T1~T6·일반 Vault 저장. 로컬 fake HTTP와 SDK 테스트는 이 성공들을 증명하지 않는다.

3R-3a 실행 결과와 다음 작업

사용자가 이 구성안을 승인해 실제 Cognito Lite pool ap-northeast-2_WpK2eiDbP, resource server, classic domain을 생성했다. 역할·정책 구성은 provider 검사 뒤로 순서를 조정했다. 실제 공개 discovery에서 issuer·code flow·HTTPS는 통과했지만 code_challenge_methods_supported 항목이 없어 S256 광고 검사는 실패했다(exit 1). PKCE 기능 자체나 OAuth 로그인 성공 여부를 검증한 것은 아니다.

승인안의 중지·정리 절차에 따라 이번 리소스를 삭제했다. 재조회에서 pool/resource server는 ResourceNotFoundException, domain은 빈 DomainDescription이었다. IAM·Lambda·GitHub·SSM·사용자·client 변경은 없고 T1~T6은 미실행이다. 공개 metadata 원문, 실행·정리 결과에 증거를 남겼다. 로컬의 해당 pool 입력/영수증은 삭제된 리소스 이력이며 다시 사용할 수 없다.

다음은 3R-3b 인증 공급자 구성 재검토다. 필수 metadata를 실제로 제공하는 구성과 기존 auth 경계의 변경 범위를 준비한다. 같은 합성 범위 승인을 반복해서 받지 않으며, 다른 공급자·권한·비용이 필요한 경우 구체적인 차이를 제시한다. HANDOFF를 갱신한 뒤 다음 작은 작업의 진행 답변을 기다린다.

3R-3b 인증 구성 재검토 결과

2026-09-05 공식 문서와 현재 auth·handler·Lambda·배포 설정을 대조했다. Auth0 관리형 인증을 우선 후보로 제안하되, 실제 tenant metadata와 토큰·회수 시험을 통과하기 전에는 채택 완료로 보지 않는다. 현재 작업은 설계 검토이며 새 계정·리소스·코드는 만들지 않았다. 목표는 MCP의 목적은 여러 모델이 같은 Vault를 이용하게 하는 것이다의 공용 접근이며 인증 서버 운영 자체를 늘리는 것이 아니다.

후보 비교

후보확인한 근거남은 조건·판정
Cognito 직접 연결 유지실제 생성 풀의 S256 광고 부재, 필수 검사 exit 1현재 구성은 제외. PKCE 기능은 AWS 문서에 있지만 discovery 지원과 별개
Auth0 관리형공식 MCP 지원 및 resource 호환 설정, 공개 무료 요금제우선 후보. 실제 tenant S256·public client·resource·회수 판정 필요
Keycloak 운영discovery·introspection·access/refresh revoke endpoint 공식 제공대안 보류. HTTPS 호스팅·상태 보존·패치 운영과 실제 resource 처리 검증 추가 필요
Cognito 앞 자체 OAuth broker자체 issuer·토큰·PKCE·상태를 모두 책임지는 별도 서버 필요단순 metadata 수정으로 해결되지 않으며 이번 작은 시험의 우선안에서 제외

OpenAI 문서는 S256 광고 누락을 미지원으로 명시한다. 필수 검사를 삭제하거나 Cognito issuer를 유지한 임의 metadata 프록시로 통과시키지 않는다. 등록은 기존 최대 4개 사전 등록 public client 방식을 유지할 수 있다. OpenAI 인증 요구, AWS PKCE·resource

Auth0의 Resource Parameter Compatibility Profile과 Include Issuer in Authorization Responses 설정을 확인한다. resource와 audience를 함께 보내면 audience가 우선하므로 두 클라이언트의 실제 요청도 확인해야 한다. 문서상 기능 지원을 tenant 활성화·실제 code 교환 성공으로 확대하지 않는다. Auth0 resource 설정, MCP 개요

Keycloak의 introspection은 confidential client 자격 증명이 필요하다. 엔드포인트 존재만으로 관리자 로그아웃·개별 회수가 현재 MCP 토큰을 즉시 거부한다는 결과를 대신하지 못한다. Keycloak 인증 엔드포인트

Auth0 변경안과 회수의 경계

Auth0 JWT 검증으로 Cognito GetUser 호출을 단순 삭제하면 현재 온라인 회수 확인 보장이 사라진다. Refresh token 회수·브라우저 로그아웃·MCP의 기존 access token 거부는 각각 시험한다. 공식 refresh 회수 문서도 사용 중인 access token과 갱신 시점을 구분하고 일부 관리 API의 Enterprise 조건을 명시한다. 이번 안은 Enterprise 관리 API나 매 요청 관리 API 호출에 의존하지 않는다. Auth0 refresh 회수

제안하는 최소 보완은 서비스에서 관리하는 접근 차단 상태다. 이는 Auth0 회수 이벤트를 자동 감지한 결과가 아니다. 관리자 절차로 MCP 차단 상태를 먼저 확정하고 Auth0 grant/refresh 회수를 따로 수행한다. Auth0 관리 화면에서만 회수했을 때 MCP가 즉시 차단됐다고 주장하지 않는다. 이 계약 변경은 사용자 검토 대상이며 기존 Cognito 회수 시험의 동등 통과로 기록하지 않는다.

  • 후보 저장소는 DynamoDB vault-protected-auth-state 1개다. 키는 고정 issuer·subject·client·resource 조합, 값은 enabled와 valid_after 시각이다. 읽기/marker runtime에는 해당 table GetItem만, 별도 관리 작업자에는 제한된 상태 쓰기만 제안한다. 실제 IAM 조건·요금은 로컬 구성 단계에서 구체화한다. 기존 승인안에는 DynamoDB가 없으므로 새 외부 범위다.
  • 요청마다 strongly consistent 읽기, 긍정 결과 캐시 없음, 없는 항목은 거부, 저장소 장애는 503으로 도구 실행 금지. JWT 검증 실패 때 상태나 GitHub 비밀을 읽지 않는다.
  • 차단은 enabled=false 저장·재조회 뒤 새 요청 거부로 정의한다. 이미 시작된 요청 취소를 보장하지 않는다. 쓰기는 commit 직전 상태를 다시 확인하되, 외부 GitHub commit과 Dynamo 상태는 원자적이지 않아 경합이 남는다는 점을 시험·보고한다.
  • 재허용 시 valid_after를 갱신해 이전 토큰이 다시 살아나지 않도록 한다. 초 단위 iat 경계는 보수적으로 거부하고 경계 이후 새 로그인 토큰으로 확인한다. 갱신 토큰까지 다시 발급 가능한지 여부는 Auth0 회수 시험으로 별도 확인한다.

파일별 변경 범위

현재 파일·구성후속 로컬 변경
auth.mjsCognito 구현 보존, Auth0 전용 adapter 추가. 고정 issuer/JWKS·RS256·aud·exp/iat/sub·client·scope와 차단 상태 검증. 토큰 profile의 client_id/azp 등은 실제 profile을 정해 명시적으로 검사
handler.mjs·reading/protected-handler.mjsCognito 전용 admin scope를 provider 설정에서 분리. read/write 분리와 오류 계약 유지
lambda.mjs·reading/lambda.mjs명시 provider 선택과 상태 조회 연결. 알 수 없는 provider 거부, 기본 비활성 유지
check-provider.mjs기존 Cognito 결과 보존, 범용 검사는 고정 승인 issuer와 HTTPS endpoint·S256·code·public token auth method를 검사. 사용자 입력을 임의 네트워크 목적지로 사용하지 않음
deployment/prepare.py·deploy/enable/cleanuppool ID 종속 제거, 실제 Auth0 issuer/client 설정·차단 table 권한·삭제 범위 추가. 삭제된 Cognito 입력 재사용 금지
로컬 시험잘못된 issuer/aud/client/sub·ID token·만료·scope·차단·상태 장애·재허용 이전 토큰·읽기/marker 격리. fake 성공과 실제 tenant 시험 분리

Auth0 token profile에 따라 claim이 달라지므로 Cognito의 token_use/client_id를 그대로 요구하거나 여러 claim 중 하나만 맞으면 허용하는 식으로 바꾸지 않는다. API access token으로 명확히 구분할 profile을 고르고 두 실제 client의 claim을 비밀 없이 대조한다. Auth0 token profiles

후속 실행 순서·새 범위

다음 작은 작업 3R-3c는 Auth0 adapter·차단 상태 계약·설정의 로컬 준비로 제안한다. 새 외부 서비스를 만들기 전에 테스트와 실제 변경안을 준비한다. 실제 tenant 연결 단계에는 다음 범위가 필요하다.

  1. 합성 시험 전용 Auth0 tenant 1개, 사용자 1명, read/marker API 식별자 2개, 사전 등록 public client 최대 4개. 자기 가입 비활성, 사용자 비밀번호·로그인은 본인이 처리. 실제 계정 로그인·tenant 지역·식별자는 아직 미확인이다.
  2. 새 DynamoDB 차단 table과 제한된 IAM 권한. 기존 Lambda 2개·SSM 3개·GitHub 합성 저장소 범위는 유지한다. Auth0에 GitHub PAT나 Vault 본문을 넣지 않는다. 인증 식별자·로그인 활동이 새 제공자에 저장되는 변경이다.
  3. Auth0 공개 가격은 Free 0/월·최대 25,000 MAU지만 해당 tenant에서 필요한 설정·API/client 한도와 trial 종료 뒤 유지 여부를 직접 확인해야 한다. 유료 가입·카드 등록·업그레이드는 이 제안에 없다. 신규 Dynamo 요청·저장 등 비용은 아직 합산하지 않았으며 이전 1 시험 목표를 검증된 총액으로 재사용하지 않는다. Auth0 요금
  4. 실제 tenant의 metadata 검사부터 수행한다. 실패하면 API/client·AWS를 더 만들지 않는다. 통과 뒤 public PKCE 정상·잘못된 verifier 거부, read/marker resource 혼용 거부, 실제 토큰 claim, 차단과 refresh 회수를 순서대로 시험한다. 이 결과 뒤에 두 클라이언트 T1~T6을 진행한다.
  5. 정리는 MCP URL 차단 → 접근 상태 disabled 확인 → Auth0 grant/refresh 회수 → 시험 client/API/user와 전용 tenant 정리 → 승인된 AWS 리소스 정리 순서다. 개인 Auth0 tenant나 기존 앱은 삭제하지 않는다. 각 단계의 부재·거부를 실제 재조회한다.

현재 판정: 공식 문서에 근거한 우선 후보와 변경안 준비 완료. Auth0 tenant·회수 구현·비용·배포·클라이언트 성공은 미검증이다. 이번에는 문서만 수정했으며 코드 테스트·빌드·클라우드 변경은 수행하지 않았다.

연결

그래프 뷰

백링크