Skip to main content

​
인증 & 보안 기초

모델 성능보다 먼저 지켜야 하는 것은 데이터 보호와 권한 통제입니다. 보안 기본이 약하면 작은 실수도 큰 사고로 이어집니다.

​
학습 목표

  • 인증(Authentication)과 인가(Authorization)를 구분할 수 있습니다.
  • OAuth, JWT, API Key 방식의 차이와 적용 기준을 설명할 수 있습니다.
  • 비밀정보(API 키, 토큰, 인증서) 관리 원칙을 적용할 수 있습니다.
  • RBAC 기반 권한 설계와 로그 보안 기본을 이해합니다.

​
왜 중요한가

AI/ML 서비스는 외부 API(LLM, 클라우드 GPU, 데이터 파이프라인)를 많이 호출합니다. 키 하나가 유출되면 수백만 원의 비용이 발생하거나, 고객 데이터가 노출될 수 있습니다. 보안은 “나중에 보강”하는 것이 아니라 첫 설계부터 내장해야 합니다.

​
핵심 개념

  • 인증(Authentication): “누구인지”를 확인합니다. (예: 로그인, API 키 검증)
  • 인가(Authorization): “무엇을 할 수 있는지”를 제한합니다. (예: 읽기만 가능, 관리자 전용)
  • 최소 권한(Least Privilege): 필요한 권한만 부여합니다.
  • 비밀 관리(Secrets Management): 코드는 공개되어도 비밀은 공개되지 않게 설계합니다.

​
인증 방식 비교

방식동작 원리장점단점적합한 상황
API Key고정 문자열을 헤더로 전송구현 간단유출 시 즉시 악용 가능서버 간 내부 통신, PoC
JWT서명된 토큰에 권한 정보 포함서버 상태 불필요(stateless)만료 전 폐기 어려움사용자 인증, 마이크로서비스
OAuth 2.0토큰 발급/갱신 프로토콜제3자 인증 위임 가능구현 복잡도 높음외부 서비스 연동, SSO

​
비밀정보 관리

코드에 키를 넣는 순간, Git 히스토리에 영구 기록됩니다. 반드시 분리하세요. 
# Bad - 절대 하지 마세요
api_key = "sk-abc123..."

# Good - 환경변수 사용
import os
api_key = os.environ["OPENAI_API_KEY"]

# Better - 시크릿 매니저 사용
import boto3
client = boto3.client("secretsmanager")
secret = client.get_secret_value(SecretId="prod/openai-key")
api_key = secret["SecretString"]
.env 파일은 반드시 .gitignore에 추가하세요. 이미 커밋된 키는 히스토리에 남으므로, 발견 즉시 폐기하고 재발급해야 합니다.

​
실무 기본 원칙

  1. API 키를 코드/노트북에 하드코딩하지 않습니다.
  2. 환경별(dev/stage/prod) 키를 분리합니다.
  3. 로그/모니터링에서 민감정보를 마스킹합니다.
  4. 키 회전 주기(90일 권장)와 폐기 절차를 운영합니다.
  5. 미사용 키는 즉시 비활성화합니다.

​
RBAC(역할 기반 접근 통제) 설계

RBAC는 사용자에게 직접 권한을 주는 대신 역할(Role) 을 부여하고, 역할에 권한을 매핑합니다.
역할권한 예시대상
viewer모델 결과 조회, 대시보드 열람일반 사용자
developer모델 배포, 데이터 읽기/쓰기개발자
admin계정 관리, 정책 변경, 키 발급운영 관리자
service-account특정 API만 호출 가능자동화 파이프라인
관리자 권한은 상시 부여하지 않습니다. 필요할 때만 임시 승격(Just-In-Time Access)하는 것이 안전합니다.

​
로그 보안

로그에 민감정보가 기록되면, 로그 접근권만으로 데이터가 유출됩니다. 
# Bad - API 키가 로그에 노출
logger.info(f"Calling API with key={api_key}")

# Good - 마스킹 처리
logger.info(f"Calling API with key=***{api_key[-4:]}")

# Good - 요청 ID만 기록
logger.info(f"API call request_id={request_id} status={status_code}")
로그 보안 원칙:
  • API 키, 토큰, 비밀번호는 로그에 절대 기록하지 않습니다.
  • 개인정보(이메일, 전화번호)는 마스킹 후 기록합니다.
  • 로그 접근 권한을 운영팀으로 제한합니다.
  • 로그 보관 기간을 규정에 맞게 설정합니다.
.env 파일을 그대로 저장소에 커밋하거나, 공유 채널에 키를 복사해 붙여넣는 실수가 가장 흔합니다. 키 유출은 “발견 즉시 폐기 + 재발급 + 영향 범위 점검”을 즉시 수행해야 합니다.
만료 시간(exp), 발급자(iss), 대상(aud), 서명 검증 여부를 확인하세요. 검증 없는 토큰 파싱은 인증 우회를 허용할 수 있습니다. JWT의 경우 alg: none 공격을 방지하기 위해 서명 알고리즘을 서버에서 강제하세요.
  1. 노출 경로 차단 2) 키/계정 회수 3) 로그 기반 영향 분석 4) 재발 방지 조치 문서화 순서로 진행합니다. 사고 대응은 속도가 핵심입니다. 발견 후 1시간 이내 키 폐기를 목표로 하세요.
사람 계정은 퇴사/이동 시 권한 회수가 필요하고, 서비스 계정은 자동화 파이프라인에 귀속됩니다. 혼용하면 퇴사자 키가 운영 시스템에 남아 보안 사각지대가 됩니다.

​
체크리스트

  • 민감정보가 코드/로그에 노출되지 않나요?
  • 권한이 역할(RBAC) 단위로 분리되어 있나요?
  • 키 회전과 폐기 절차가 문서화되어 있나요?
  • 사고 발생 시 대응 담당/순서가 정의되어 있나요?
  • .env 파일이 .gitignore에 포함되어 있나요?
  • 로그에서 민감정보 마스킹이 적용되고 있나요?
  • 미사용 키와 계정을 정기적으로 정리하고 있나요?

​
다음 문서