사내에서 로컬 추론 API를 쓰기 전에. 인증, 허가 목록, 단말 퇴역의 설계

안녕하세요, Cor.주식회사의 데라다입니다. 오늘은 소박한 이야기입니다. 사내에서 로컬 AI를 돌린다면 먼저 정해 두고 싶은 이야기입니다.

손안에서 쓰는 전제

로컬에서 추론을 돌리는 도구의 다수는, 먼저 눈앞의 컴퓨터에서 쓰는 것을 전제로 합니다.

예를 들어 Ollama 공식 문서에는 localhost의 로컬 API는 인증이 필요 없다고 적혀 있습니다. 또한 기본값은 로컬(127.0.0.1)에서 기다리고, 설정으로 대기 주소를 바꿀 수 있다고도 적혀 있습니다.

이것은 결함이라기보다 설계의 전제입니다. 손안에서 쓰는 동안에는 그 전제로 충분합니다. 문제가 나는 것은 이 전제 그대로 사내 네트워크로 넓힐 때입니다.

로컬 API를 호출하는 것과, 처리 전체가 손안에서 끝나는 것은 같지 않습니다. 고르는 모델에 따라 밖으로 나가는 경로를 쓰는 구성도 있습니다. 고른 모델과 바깥으로 나가는 통신도 확인합니다.

「사내」라는 말

사내용으로 추론 서버를 세우면, 다른 단말에서도 쓰도록 대기를 넓힙니다. 방화벽으로 어느 단말에서 도달해도 되는지를 정합니다. 여기까지는 보통의 순서입니다.

조심할 것은 그 다음입니다.

시험으로 연 대기가 그대로 남습니다. 일시적으로 넣은 허가 대상이 그대로 남습니다. 더 이상 쓰지 않는 단말의 허가가 대장에서는 지워졌는데 방화벽에는 남습니다.

인증이 없는 API에서는 「도달한다」가 거의 「쓸 수 있다」를 뜻합니다. 그래서 의도하지 않은 단말에서 도달할 수 있는 상태가 남는 것 자체가 위험이 됩니다. 「사내만」이라는 말은 실제 허가 설정이 따라와야 비로소 의미가 있습니다.

허가 목록으로 알 수 있는 것

허가 목록으로 알 수 있는 것은 통신을 통과시켜도 되는 상대입니다. 그것만으로 누가 어떤 업무에 써도 되는지까지 정해지지는 않습니다. 여러 사람이 쓸 때는 앞단의 인증, 이용자나 서비스별 권한, 실효 때의 동작도 따로 설계하는 항목입니다. 이것은 Cor.주식회사가 그 구현을 끝냈다는 보고가 아닙니다.

취약점 대응과 허가 설정

취약점 대응과 허가 설정의 관리는 어느 한쪽만으로 끝나지 않습니다. 업데이트 정보를 따라가는 것에 더해, 어느 단말이 어떤 용도로 언제까지 접속해도 되는지를 계속 확인합니다.

취약점 정보(CVE)는 어느 날 한꺼번에 나옵니다. 허가 설정의 어긋남은 매일 조금씩 쌓입니다. 후자는 절차가 없으면 알아채기 어렵습니다. 둘 다 절차 안에 둡니다.

받아들이는 순서

새 단말에 추론 API를 쓰게 할 때, Cor.주식회사는 받아들이기에서 이 순서를 둡니다.

1. 대장에 단말을 등록한다(용도, 담당, 이용 기한)
2. 단말 쪽의 기본 설정을 확인한다
3. 방화벽의 허가 대상에 추가한다
4. 도달하는 것을 확인하고, 확인일을 대장에 남긴다

대장이 먼저, 허가가 나중입니다. 허가만 먼저 들어가면 「누구의 무엇을 위한 허가인지」를 나중에 좇을 수 없게 됩니다.

퇴역의 순서

단말을 뺄 때는 반대로 합니다.

1. 방화벽의 허가 대상에서 삭제한다
2. 도달하지 않게 된 것을 확인한다
3. 단말 쪽의 자격 증명과 설정을 정리한다
4. 대장을 「퇴역」으로 갱신하고 날짜를 남긴다. 행은 지우지 않고 이력으로 남긴다

허가를 먼저 지웁니다. 대장만 갱신하고 허가가 남는 것이 가장 나기 쉬운 어긋남입니다.

침해가 의심될 때는 위의 퇴역 절차와 다릅니다. 격리와 자격 증명의 실효를 먼저 합니다. 의심스러운 단말을 보통의 폐지 순서로 다루지 않습니다.

확인할 항목

개별 사례가 아니라, 다른 회사에서도 쓸 수 있는 형태로 모아 둡니다. 여기에는 측정값을 싣지 않았습니다. 실효가 반영되기까지의 시간은 요건으로 정합니다. 잰 값이 있을 때만 그 값을 씁니다.

• 추론 API의 대기 주소를 의도한 범위로 한정했는가
• 검증용으로 넓힌 대기를 검증 뒤에 되돌렸는가
• 방화벽의 허가 대상 목록과 단말 대장이 일치하는가
• 허가 대상마다 용도, 담당, 기한이 대장에 있는가
• 퇴역 때 「허가 삭제, 도달하지 않음의 확인, 대장 갱신」 순서로 처리하는가
• 허가 목록과 대장을 정기적으로(예를 들어 매월) 맞추어 보는가
• 누가 언제 어느 허가를 더하고 뺐는지 기록이 남는가
• 인증이 없는 API를 밖으로 내야 할 때, 앞단에 인증이나 접근 제어를 두는 설계인가
• 허가한 단말에서 도달하는 것뿐만 아니라, 허가하지 않은 단말은 거부되는가
• 실효 뒤에 거부되는가
• 서비스를 멈췄을 때 어떻게 동작하는가
• 고른 모델과 바깥으로 나가는 통신이 가정한 범위인가

이 목록이 돌고 있으면 어긋남을 알아채기 쉬워집니다. 모든 어긋남이 발견된다는 뜻은 아닙니다.

함께 보는 범위

Cor.주식회사는 기존 설비를 출발점으로, 로컬에서 처리하는 범위를 함께 봅니다. ISMS 운용 안에서 구성의 선정과 권한, 실효, 로그의 설계를 함께 합니다. ISMS는 2026년 10월에 ISO/IEC 27001 2단계 심사를 마치고, 2026년 12월경에 인증 등록을 예상하고 있습니다.

이번 허가 목록 이야기는 그 「실효」와 「로그」의 이야기입니다. 추론 성능뿐만 아니라, 어느 단말이 언제까지 도달해도 되는지를 설명할 수 있는 것도 운용의 조건입니다. 성능 요건을 여기서 부정하는 것은 아닙니다.

설명할 수 있는 범위

인증이 없다고 들으면 불안해질 수 있습니다. 그것은 도구의 전제를 알았다는 것일 뿐입니다. 전제를 알면 지킬 범위도 보입니다.

누구의 단말이 언제부터 언제까지 도달해도 되는가. 그것을 대장과 허가 설정 양쪽에서 설명할 수 있는 것. Cor.주식회사가 남기고 싶은 것은 거기입니다. 허가 목록만으로는 이용자의 권한까지 정해지지 않습니다.

참고 자료

• Ollama Docs: Authentication - localhost의 로컬 API(포트 11434)는 인증이 필요 없다는 기술(2026년 10월 27일 확인)
• Ollama Docs: FAQ - 「How can I expose Ollama on my network?」 항. 기본값은 127.0.0.1의 포트 11434에서 대기하고, 환경 변수 OLLAMA_HOST로 대기 주소를 바꿀 수 있다는 기술(2026년 10월 27일 확인)
• Cor.주식회사: 보안 - ISMS를 운용하고 있으며, 2026년 10월에 ISO/IEC 27001 2단계 심사를 마치고, 2026년 12월경에 인증 등록을 예상한다는 점