예약 작업과 사람 로그인: API는 어느 신원을 보아야 하는가

예약된 작업과 로그인 프롬프트 앞에 선 사람은 같은 API를 서로 다른 자격 증명, 서로 다른 수명, 서로 다른 소유자로 호출합니다. 작업에는 네트워크 경로, 애플리케이션 신원, 권한 집합이 필요하고, 사람에게는 로그인, 두 번째 요소, 세션이 필요합니다. 둘을 섞으면 사람의 비밀번호가 바뀔 때마다 깨지는 자동화가 생기거나, cron 작업을 살려 두기 위해 딱 그만큼 약화된 다중 요소 정책이 생깁니다.

하나처럼 보이는 세 개의 문

소스 주소 규칙은 요청이 어디서 왔는지 묻습니다. 인증은 누가 호출하는지, 어떤 증명이 제시되었는지 묻습니다. 권한 부여는 이 주체가 이 작업을 수행할 수 있는지 묻습니다. VPN은 셋 중 첫 번째만 바꾸며, 작업만이 아니라 호스트의 모든 프로세스에 대해 바꾸므로 사고 기록에서 세 가지 관찰을 분리해 두세요.

그래서 출구 노드를 바꾸면 소스 주소 때문에 생긴 거부는 고칠 수 있어도 유효하지 않은 토큰은 그대로 남습니다. 그래서 유효한 API 토큰이 있어도 그곳으로 가는 경로가 없는 작업에서 사설 엔드포인트에 닿을 수는 없습니다.

대화형 경로는 형편없는 자동화 템플릿이다

사람의 로그인을 스크립트로 만드는 것은 한 번은 동작하기 때문에 솔깃합니다. 스크립트는 비밀번호, 어쩌면 일회용 비밀번호 시드를 저장하고, 사람을 요구하도록 설계된 챌린지에 의존합니다. OAuth의 현재 모범 보안 관행인 RFC 9700은 resource-owner-password-credentials 부여를 금지하고, 그것이 이중 요소 및 다단계 인증에 왜 잘 맞지 않는지 설명합니다.

지원되는 대안은 보통 기밀 클라이언트 흐름으로, 권한 서버가 애플리케이션을 인증하고 토큰을 발급합니다. RFC 6749의 4.4절에 있는 client-credentials 부여가 그 한 예입니다. 그것이 존재한다고 해서 모든 API가 이를 받아들이는 것도, 사용자가 위임한 작업을 그것으로 대체할 수 있는 것도 아니며, 그것은 서비스 소유자에게 할 질문입니다. 코드를 쓰기 전에 서비스가 어떤 무인 모델을 지원하는지 물으세요.

VPN이 여전히 어울리는 자리

VPN은 사설 API가 요구하는 네트워크 경로를 제공할 수 있고, 그것은 정당한 역할입니다. VPN은 작업을 애플리케이션에 인증하지 않으며, 작업이 무엇을 할 수 있는지 범위를 정하지도 않습니다. 공유 출구 주소는 작업이 아니라 호스트를 식별하므로, 그 주소에 대한 허용 목록 항목은 그 위에서 도는 모든 프로세스를 통과시킵니다.

작업이 공유 러너에서 돌면 그 구분은 덜이 아니라 더 중요해집니다. 같은 호스트의 다른 워크플로가 경로와 주소를 물려받고, API는 둘을 구별할 수 없습니다. 공유 비밀번호와 같은 약점이 한 계층 아래로 옮겨진 것입니다. 제한은 애플리케이션이 강제할 수 있는 곳에 두고, 허용 목록을 더 좁힐 수 없다면 러너를 격리하세요.

두 설계를 정직하게 비교하라

사람의 로그인은 실제 사람, 실제 두 번째 요소, 감사 가능한 세션을 주지만 무인으로 돌 수 없습니다. 애플리케이션 신원은 무인 실행, 검토 가능한 범위, 회전할 수 있는 자격 증명을 주지만 아무것도 위임하지 않은 사용자를 대신할 수는 없습니다. 어느 쪽도 다른 쪽의 약한 버전이 아니며, 서로 다른 질문에 답합니다. 작업이 아무도 없는 상태에서 돌아야 하는지, 작업을 특정 사용자에게 귀속해야 하는지 물어서 고르세요.

두 답이 모두 예라면 설계에는 빌려온 비밀번호가 아니라 위임 모델이 필요합니다. 그 결정을 다음 유지보수자가 찾을 수 있는 곳에 적어 두세요.

인계 전에 확인할 것

실제 워커에서 허용된 작업 하나와 반드시 거부되어야 할 작업 하나를 실행하고 두 결과를 모두 보관하세요. 그다음 밤에 누군가를 깨우는 두 가지 실패이므로, 만료된 자격 증명과 네트워크 경로를 쓸 수 없을 때의 동작을 시험하세요.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

주체, 범위, 회전 소유자, 실행 환경을 그 결과 옆에 기록하세요. 그 기록이 다음 회전을 사고가 아니라 일상으로 만듭니다. 감사자가 요구하는 것도 그 부분입니다.