다가오는 libcurl의 NTLM 제거는 기술적으로 보이지만 실제로는 조직적인 변경 중 하나입니다. Azure DevOps Server로 가는 HTTPS 통한 Git 경로가 여전히 NTLM에 의존한다면, 문제는 툴링이 아니라 아이덴티티 부채입니다.
Microsoft가 여기서 강력히 밀어붙이는 것은 옳습니다. NTLM은 알려진 암호화 취약점이 있으며 현대 엔터프라이즈 기본값이 되어서는 안 됩니다. 위험한 부분은 많은 환경이 Kerberos를 사용하고 있다고 믿지만 실제로는 NTLM으로의 무음 SPNEGO 폴백으로 유지되고 있다는 것입니다. 그 환상은 2026년 9월에 사라집니다.
내 의견: 이것을 “클라이언트 버전” 문제로 취급하지 마세요. NTLM 플래그를 다시 활성화하고, 이전 Git 빌드를 고정하거나, 폴백이 계속 가능하기를 바라는 것은 장기적 위험이 있는 단기 해결책입니다. 완화 전략이 다운그레이드 및 지연이라면, 운영 취약성을 적극적으로 증가시키는 것입니다.
실용적인 마이그레이션 순서는 직설적이고 측정 가능해야 합니다.
- 지금 현재 인증 동작을 확인하세요. 실제 개발자 및 빌드 에이전트 컨텍스트에서 도메인 외부 및 원격 네트워크 경로를 포함하여 트레이스 기반 검사와 티켓 캐시 검증을 실행하세요.
- Kerberos를 종단간 수정하세요: SPN, DNS 별칭, 로드 밸런서 설정, 위임, 도메인 컨트롤러 연결성.
- 도메인에 가입되지 않았거나 작업 그룹 시나리오를 조기에 식별하고 Kerberos를 신뢰할 수 있게 만들 수 없는 곳에 SSH 레인을 설계하세요.
또한 소유권 명확성이 필요합니다. 보안 팀은 정책 기준을 정의해야 하지만, 플랫폼 엔지니어링이 구현 준비를 소유해야 합니다. 이것은 개별 리포지토리 관리자를 위한 사이드 태스크가 될 수 없습니다. IIS, AD, 네트워크 에지, CI 에이전트, 개발자 워크스테이션 지침 전반에 걸친 조정된 변경이 필요합니다.
한 가지 미묘한 위험은 자동화입니다. 빌드 에이전트와 서비스 계정은 인간 사용자가 괜찮을 때에도 Kerberos 티켓이 없거나 유효하지 않은 컨텍스트에서 자주 실행됩니다. 대화형 개발자 워크플로만 테스트하면 가장 중요한 중단점을 놓칠 것입니다.
이점은 실제입니다. Kerberos 또는 SSH로 깔끔하게 이동하면 중단을 피할 뿐만 아니라 공격 표면을 줄이고 아이덴티티 제어를 현대 규정 준수 기대치와 정렬합니다. 지금 이 전환을 시작하는 팀은 9월을 무사히 넘길 것입니다. 기다리는 팀은 릴리스 압박 아래 인증 오류를 디버깅하게 될 것입니다.
이것은 보관할 경고가 아닙니다. 실행해야 할 마감일입니다.
