AI API 보안을 위한 최고의 암호화 방식

한 줄로 요약하자면 이렇습니다. TLS 1.3이 기본이고, mTLS는 기계 신원을 증명하며, 페이로드 암호화는 TLS가 끝난 뒤에도 여전히 중요한 데이터를 보호합니다.

AI API 공격은 2022년 상반기부터 2023년 상반기까지 681% 급증했습니다. 그래서 AI API를 보호할 때 저는 하나의 해결책을 찾지 않습니다. 레이어 를 봅니다. 이 글은 가장 중요한 관점들에 걸쳐 7가지 암호화 방식을 비교합니다.

• 보안 범위
• 성능 비용
• 키 관리 노력
• 전송 계층 대 애플리케이션 계층 커버리지
• 미국 배포 적합성

간단히 정리하면 이렇습니다.

• 대칭 암호화는 대용량 페이로드와 저장 데이터에 가장 적합합니다.
• 공개 키 암호화는 키 교환과 서명에 가장 적합합니다.
• 하이브리드 암호화는 둘을 섞어, 대부분의 애플리케이션 계층 사용 사례에 맞습니다.
• TLS 1.2/1.3은 전송 중 데이터를 보호하며, TLS 1.3이 기본값입니다.
• mTLS는 연결의 양쪽 모두를 확인합니다.
• 필드 수준 암호화는 숨겨져야 하는 필드만 보호합니다.
• 엔벨로프 암호화는 대규모 키 순환을 훨씬 쉽게 만듭니다.

핵심: 전송 보안은 TLS 종료에서 멈춥니다. 그 지점 이후에도 프롬프트, 이미지, 오디오, 로그, 큐 또는 백업이 여전히 보호가 필요하다면, 저는 또 다른 레이어가 필요합니다.

AI 앱에서 민감한 데이터 보호하기

빠른 비교

그래서 짧은 답을 원한다면 이렇습니다. 기본적으로 TLS 1.3을 쓰고, 서비스 신원을 위해 mTLS를 추가하며, 데이터가 연결 자체를 넘어 보호되어야 할 때는 필드 수준, 하이브리드, 또는 엔벨로프 암호화를 쓰세요.

1. 대칭 암호화

대칭 암호화는 대량 데이터를 보호하는 빠른 방법입니다. 하지만 그것만으로 키 교환을 해결하지는 못합니다. 암호화와 복호화 모두에 하나의 공유 키를 사용하며, 이것이 AI API 보안의 핵심 부분이 되게 합니다. 보통 AES-256-GCM 을 선택하는데, 빠르고 무결성 검사가 내장되어 있기 때문입니다 ^[4][10].

보안 범위

AES-256-GCM은 두 곳에서 잘 작동합니다. 저장 데이터와 전송 중 데이터입니다. 여기에는 저장된 학습 세트, 모델 가중치, 아카이브된 출력, 그리고 TLS 1.3 내부에서 사용되는 대량 암호화가 포함됩니다 ^[3][2]. GCM은 AEAD 모드이기 때문에 기밀성을 보호하고 프롬프트나 멀티모달 페이로드의 변조를 잡아내는 데 도움이 되는 인증 태그를 추가합니다 ^[4].

무시할 수 없는 한 가지 한계가 있습니다. 대칭 암호화는 데이터가 모델에 도달할 때까지만 보호합니다. 추론 중에는 모델이 평문으로 작업해야 합니다. 즉, 평문 데이터가 여전히 RAM이나 GPU 메모리에서 노출될 수 있습니다 ^[7].

성능 영향

AES-256-GCM은 AES-NI를 지원하는 표준 서버 CPU에서 4.2 GB/s 에 도달할 수 있습니다 ^[8]. 쉽게 말해, 작은 프롬프트를 암호화하는 데 마이크로초가 걸리며, 이는 네트워크 지연이나 모델 실행 시간보다 훨씬 짧습니다 ^[8].

AES-NI가 없는 모바일 클라이언트나 엣지 기기에서는 보통 ChaCha20-Poly1305 가 더 나은 선택입니다. 소프트웨어 성능에 맞게 조정되어 Apple A17 Pro 같은 하드웨어에서 3.4 GB/s 에 도달하며, 동일한 256비트 보안 수준을 제공합니다 ^[8].

키 관리

여기에 함정이 있습니다. 양쪽 모두 같은 비밀이 필요합니다. 그래서 어려운 부분은 그 키를 안전하게 공유하는 것이며, 이는 보통 비대칭 암호를 끌어들이는 것을 의미합니다.

대규모에서는 팀이 종종 대칭 키를 KEK로 래핑하여 전체 페이로드를 다시 암호화하지 않고도 데이터를 다시 키잉할 수 있게 합니다 ^[2][11]. KEK 순환은 자동화되어야 하며, 키는 구성 파일이나 앱 소스 코드가 아니라 FIPS 140-3 Level 3 검증 HSM 이나 전용 시크릿 매니저에 있어야 합니다 ^[11][10].

그 공유 키 문제가 바로 비대칭 암호화가 다음에 오는 이유입니다.

최적 AI API 사용 사례

대칭 암호화는 대량 페이로드에 적합합니다. 고해상도 이미지, 영상 파일, 긴 오디오 클립, 큰 JSON 요청 본문을 생각해 보세요 ^[4]. 또한 장기 아카이브와 테넌트별 격리에도 잘 작동하는데, 여기서는 DEK를 테넌트별 키로 래핑하여 데이터를 분리된 상태로 유지합니다 ^[2][10].

하지만 전송과 키 교환의 경우, 대칭 암호화는 스택의 한 부분일 뿐입니다.

2. 비대칭 암호화

비대칭 암호화는 대칭 암호화가 잘 처리하지 못하는 부분을 다룹니다. 안전한 키 교환과 신원 확인입니다. 두 개의 연결된 키를 사용합니다.

• 누구나 접근할 수 있는 공개 키
• 소유자만 보관하는 개인 키

데이터가 공개 키로 암호화되면, 짝이 맞는 개인 키만이 이를 복호화할 수 있습니다.

보안 범위

비대칭 암호화가 중요한 이유는 TLS가 끝난 뒤에도 민감한 페이로드를 보호된 상태로 유지할 수 있기 때문입니다. TLS는 첫 홉의 트래픽을 보호합니다. 하지만 트래픽이 그 지점을 지나가면, 그 레이어는 사라집니다.

바로 그때 메시지 수준 암호화가 등장합니다. 데이터를 비대칭 키로 암호화하면, 프롬프트 안의 PII 같은 민감한 콘텐츠가 내부 로깅 시스템, 서비스 메시, 분산 트레이싱 파이프라인을 거치는 동안에도 암호화된 상태를 유지할 수 있습니다 ^[4][12].

또한 디지털 서명도 지원합니다. 그 서명은 프롬프트가 주장된 발신자로부터 왔음을 검증하고 부인 방지를 제공하는 데 도움이 됩니다 ^[4].

트레이드오프는 단순합니다. 이 수준의 보호는 연산에서 훨씬 더 큰 비용이 듭니다.

성능 영향

비대칭 암호화는 이미지, 영상, 오디오 같은 대용량 페이로드에는 너무 느립니다. 대량 데이터가 아니라 키와 서명에 사용하세요 ^[14].

서명의 경우 ECC 와 Ed25519 가 RSA보다 성능이 좋고 현대 AI API 인증에 더 잘 맞습니다 ^[14].

키 관리

개인 키는 FIPS 140-3 Level 3 검증 HSM이나 신뢰 실행 환경(TEE)에 있어야 합니다 ^[10]. 공개 키는 종종 JWKS (JSON Web Key Set) 엔드포인트 를 통해 공유되며, 이를 통해 API 파트너가 키를 자동으로 찾고 확인할 수 있습니다 ^[5].

키가 손상되었을 때 피해를 제한하기 위해 키 순환은 90일 주기로 이루어져야 합니다 ^[5].

여기서 비용 격차는 무시하기 어렵습니다. AWS KMS 에서 비대칭 RSA 연산은 1만 건당 최대 $12.00 가 들 수 있는 반면, 대칭 연산은 1만 건당 약 $0.03 가 듭니다 ^[14].

최적 AI API 사용 사례

비대칭 암호화는 키 교환과 인증에 가장 적합합니다. 멀티 테넌트 AI API에서는 대칭 키를 래핑하고 프롬프트 진위를 검증하는 데 가장 자주 쓰입니다 ^[4]. 또한 mTLS 를 통한 클라이언트 인증도 지원합니다 ^[1].

지금 팀이 계획해야 할 또 다른 문제가 있습니다. 포스트 양자 마이그레이션입니다. 표준 RSA와 ECC는 미래의 양자 공격에 취약해질 것입니다. NIST는 2024년 8월 에 첫 포스트 양자 암호 표준인 FIPS 203, 204, 205 를 확정했으며, 초기 벤치마크는 표준 서버 하드웨어에서 ML-KEM 이 RSA-2048 대비 5% 미만 의 성능 오버헤드를 더한다는 것을 보여 줍니다 ^[3][10].

실제로 비대칭 암호화는 키를 보호하고, 대칭 암호화는 페이로드를 보호합니다.

3. 하이브리드 암호화

하이브리드 암호화는 무작위 대칭 DEK로 페이로드를 보호한 다음, 그 DEK를 비대칭 공개 키로 래핑합니다. 간단히 말해, 데이터 자체에는 암호화의 빠른 부분을 쓰고, 키에는 공개 키 부분을 씁니다. 이는 데이터가 여전히 내부 시스템을 거칠 수 있는 TLS 종료 이후에 가장 중요합니다.

보안 범위

하이브리드 암호화는 서비스 메시, 프록시, 로그 내부를 포함해 TLS 종료 이후에도 페이로드를 암호화된 상태로 유지합니다. 각 요청은 자체 단기 DEK를 받으며, 이는 하나의 키가 노출되었을 때 피해 반경을 줄여 줍니다.

AES-256-GCM 을 사용하면 인증 태그도 추가됩니다. 그 태그는 AI 시스템이 페이로드에 손대기 전에 변조를 잡아내는 데 도움이 됩니다. 전송의 경우, 이 레이어는 TLS를 대체하는 것이 아니라 TLS와 함께 작동합니다.

성능 영향

하이브리드 셋업에서 비대칭 단계는 DEK만 래핑합니다. 페이로드 자체의 무거운 작업은 AES 가 처리합니다. 그래서 이 모델은 영상, 고해상도 이미지, 오디오 스트림 같은 대용량 멀티모달 요청에도 대규모에서 속도를 크게 떨어뜨리지 않고 잘 작동합니다.

키 관리

KEK를 HSM 에 보관하고, 각 요청마다 단기 DEK를 생성하며, key_id 를 붙여 DEK를 페이로드 재암호화 없이 다시 래핑할 수 있게 하세요. 그 셋업은 키 순환을 훨씬 덜 고통스럽게 만듭니다.

멀티 테넌트 AI 플랫폼의 경우, 암호화 파쇄(crypto-shredding) 도 지원합니다. 테넌트의 마스터 키를 파기하면, 각 레코드나 백업을 하나하나 건드리지 않고도 연결된 모든 암호화 페이로드를 읽을 수 없게 됩니다.

최적 AI API 사용 사례

하이브리드 암호화는 데이터가 TLS 종료 이후 신뢰 경계를 넘는 AI API 경로에 적합합니다. 예를 들면 이렇습니다.

• 멀티 홉 아키텍처
• 리버스 프록시
• 로드 밸런서
• 서비스 메시

또한 제공자가 평문을 결코 다루지 않는 제로 지식 워크플로에도 맞습니다.

포스트 양자 마이그레이션의 경우, 래핑 레이어만 바꾸면 됩니다. RSA나 ECDH를 ML-KEM (FIPS 203) 으로 교체하면 나중에 복호화될 수 있는 저장된 암호문을 보호하는 데 도움이 되며, AES-256 대칭 레이어는 그대로 유지됩니다 ^[10]. 하이브리드 암호화는 TLS를 넘어선 페이로드 보호를 처리하며, 다음 레이어는 TLS와 mTLS를 통한 전송 인증입니다.

4. TLS 1.2/1.3

TLS는 모든 AI API의 기본 전송 보안 레이어입니다. TLS 1.3이 기본값이어야 합니다. 하이브리드 암호화가 네트워크 경계를 넘어선 데이터를 보호한다면, TLS는 네트워크 자체를 건너는 여정을 보호합니다. 간단히 말해, TLS는 전송 중 데이터를 보호하고, 페이로드 암호화는 TLS가 끝난 뒤에도 여전히 노출될 수 있는 것을 다룹니다.

보안 범위

TLS 1.3은 RC4, DES, 3DES 같은 취약한 레거시 암호 스위트를 제거합니다. TLS 1.2는 직접 끄지 않으면 여전히 이를 허용할 수 있습니다 ^[10][18]. TLS 1.3은 또한 완전 순방향 비밀성(PFS)을 요구하고 핸드셰이크 중 클라이언트 인증서를 암호화하여, 내부 서비스 관계에 대한 수동 모니터링을 훨씬 어렵게 만듭니다 ^[15][17].

성능 영향

TLS 1.3은 핸드셰이크를 2 RTT에서 1 RTT로 줄입니다 ^[15][9]. 작게 들릴 수 있지만, 실시간 오디오나 영상 스트리밍 같은 고빈도 워크로드에서는 p99 지연 시간을 줄이고 CPU 부하를 덜어 줍니다.

TLS 1.3은 또한 0-RTT 재개를 허용하여, 재개된 세션이 곧바로 데이터를 보낼 수 있습니다. 빠르지만 트레이드오프가 있습니다. 0-RTT에는 재전송 리스크가 있습니다. 민감한 API 경로에는 0-RTT를 비활성화하세요 ^[16].

키 관리

인증서 처리는 많은 팀이 예리하게 유지되거나 허술해지는 지점입니다. 더 안전한 길은 단순합니다.

• 인증서를 90일마다 순환하세요 ^[16][9]
• Let's Encrypt 같은 공개 엔드포인트에는 자동 발급을 사용하세요 ^[1]
• 개인 키를 내보내기 가능한 PEM 파일이 아니라 HSM이나 TEE에 저장하세요 ^[3][10]
• 규제 셋업에서는 FIPS 140-3 검증 모듈을 사용하세요 ^[10]
• TLS 1.2를 업그레이드할 수 없다면, 순방향 비밀성이 유지되도록 ECDHE 기반 암호 스위트만 허용하세요 ^[10]
• OCSP 스테이플링을 활성화하여 인증서 확인이 더 빨라지고 핸드셰이크 중 또 다른 네트워크 왕복을 더하지 않도록 하세요 ^[9]

최적 AI API 사용 사례

TLS 1.3은 공개 엔드포인트, 브라우저 앱, 실시간 멀티모달 WebSocket 스트림에 적합한 기본값입니다 ^[15][16]. TLS 1.2는 오래된 엔터프라이즈 통합을 위한 호환성 하한선으로 여전히 허용되지만, PFS 전용 암호 스위트로 잠겨 있을 때만 그렇습니다 ^[10].

서비스 간 트래픽의 경우, mTLS가 신원 검증을 더합니다.

5. 상호 TLS (mTLS)

mTLS는 앱 데이터가 전송되기 전에 인증서로 클라이언트와 서버 양쪽 모두를 확인하여 TLS 위에 구축됩니다.

보안 범위

이는 API 키가 남기는 공백을 메웁니다. API 키는 비밀을 증명합니다. 어떤 워크로드가 호출하고 있는지는 증명하지 않습니다.

AI 에이전트, 마이크로서비스, 기타 워크로드 신원의 경우, mTLS는 접근을 검증된 서비스로 제한합니다. 이는 민감한 모델 엔드포인트와 시스템이 이미지, 음성 같은 멀티모달 데이터를 교환할 때 중요합니다 ^[15][13][20].

성능 영향

주된 단점은 추가 핸드셰이크 작업입니다. mTLS는 보통 표준 TLS보다 약 1~2밀리초의 지연 시간 과 5~10% 더 많은 핸드셰이크 시간 을 더합니다 ^[21].

그 부담을 줄이는 흔한 방법은 API 게이트웨이나 엣지 방화벽에서 mTLS를 종료하는 것입니다. 이는 비대칭 암호 작업을 모델 런타임에서 떼어 놓습니다 ^[17][15]. 연결 풀링과 keep-alive 헤더도 그 비용을 매번 처음부터 지불하는 대신 여러 요청에 분산시키는 데 도움이 됩니다 ^[21].

키 관리

mTLS는 인증서 발급, 순환, 폐기를 위한 강력한 PKI 프로세스가 필요합니다 ^[6][19]. 이 부분은 대충 다룰 수 없습니다. 인증서 갱신을 놓치면, 서비스 간 트래픽이 그 자리에서 실패할 수 있습니다 ^[19].

대규모에서 발급, 순환, 폐기를 처리하려면 자동화된 PKI 도구를 사용하세요. 개인 키의 경우, PKCS#11 을 통한 HSM 이나 TPM 같은 하드웨어 기반 저장소가 키를 내보내기 불가능하게 유지하는 데 도움이 됩니다 ^[13]. 단기 인증서도 리스크를 줄입니다. SPIFFE 는 워크로드 신원에 대해 1시간 만큼 짧은 수명을 권장합니다 ^[21].

최적 AI API 사용 사례

mTLS는 기계 대 기계 트래픽에 가장 적합합니다. 내부 데이터베이스를 호출하는 AI 에이전트, 민감한 멀티모달 데이터를 전달하는 마이크로서비스, 출처에 대한 암호학적 증명이 필요한 규제 통합을 생각해 보세요. 이러한 셋업에서 mTLS는 API 키 인증과 함께 추가 인증 레이어로 작동합니다 ^[15][20].

연결 계층의 신원에는 mTLS를 사용하세요. 특정 필드가 전송 이후에도 보호되어야 할 때는 필드 수준 암호화를 사용하세요.

6. 필드 수준 암호화

mTLS는 누가 호출하는지 알려 줍니다. 필드 수준 암호화는 그들이 보내는 것 안의 민감한 값을 보호합니다.

핵심 차이는 단순합니다. 전체 페이로드를 암호화하는 대신, 필드 수준 암호화는 전송이 끝난 뒤에도 숨겨져야 하는 필드만 다룹니다. 즉, TLS와 mTLS가 자기 역할을 마친 뒤에도 그 보호가 여전히 중요합니다.

보안 범위

TLS는 전송 중 데이터를 보호합니다. 필드 수준 암호화는 TLS가 끝난 뒤 데이터 자체를 보호합니다.

이 접근은 사회 보장 번호, 의료 기록, 전체 결제 카드 번호처럼 특별한 주의가 필요한 필드만 암호화합니다. 그 결과, 이러한 값은 로그, 큐, 백업, 데이터베이스 덤프처럼 데이터가 종종 남는 곳에서도 암호화된 상태를 유지합니다.

하지만 트레이드오프가 있습니다. 모델은 평문으로 남겨진 필드로만 작업할 수 있습니다. 그래서 모델이 자기 일을 하는 데 어떤 값이 필요하다면, 그 필드는 추론 시점에 암호화된 상태로 둘 수 없습니다. 실제로 이는 모델이 필요로 하지 않는 것만 암호화해야 한다는 뜻입니다. 또한 보호되는 각 필드마다 작은 처리 비용이 있습니다.

성능 영향

필드 수준 암호화는 보통 5%에서 10%의 지연 시간 을 더하는데, 보호되는 각 필드가 개별적으로 암호화되고 복호화되어야 하기 때문입니다.

그 비용은 보통 괜찮지만, 키 처리와 필드 ID가 깔끔하게 유지될 때만 그렇습니다. 그렇지 않으면 오버헤드가 빠르게 쌓일 수 있습니다.

키 관리

필드 수준 암호화에는 가장 중요한 세 가지 통제가 따릅니다.

• 테넌트별 키 격리를 사용하세요. 모든 테넌트가 하나의 키를 공유하면, 단 한 번의 손상으로 모두의 데이터가 노출될 수 있습니다 ^[10].
• 각 암호화 필드 옆에 키 ID나 버전 태그를 포함하여, 기존 레코드를 깨뜨리지 않고 순환 이후에도 레거시 데이터를 복호화할 수 있게 하세요 ^[1].
• 하나의 테넌트가 손상되었을 때 노출을 제한하려면 테넌트별 필드 키를 사용하세요.

최적 AI API 사용 사례

필드 수준 암호화는 프롬프트의 작은 부분만 비밀로 유지되어야 하고 나머지는 여전히 모델이 사용할 수 있어야 할 때 가장 적합합니다.

• 멀티 테넌트 AI SaaS - 테넌트별 키는 하나의 테넌트가 손상되었을 때 피해 반경을 제한합니다.
• 외부 로깅 파이프라인 - 로그가 플랫폼 밖으로 전송되어도 PII가 암호화된 상태를 유지합니다.
• 헬스케어 또는 금융 AI API - 민감한 필드가 로그, 데이터베이스 덤프, 큐, 백업에서 암호화된 상태를 유지합니다.
• 부분 추론 워크플로 - 모델이 민감하지 않은 필드만 읽습니다.

7. 엔벨로프 암호화

엔벨로프 암호화는 키 순환을 악몽으로 만들지 않으면서 대용량 페이로드를 보호하는 실용적인 방법입니다. 아이디어는 단순합니다. 데이터를 DEK로 암호화한 다음, 그 DEK를 KEK로 암호화합니다.

쉽게 말해 이렇게 작동합니다. 무작위 데이터 암호화 키(DEK)가 텍스트든 이미지든 영상 파일이든 실제 AI 페이로드를 AES-256 같은 빠른 대칭 암호화로 암호화합니다. 그런 다음 KMS 나 HSM 에 보관된 키 암호화 키(KEK)가 DEK 자체를 암호화합니다. 저장하거나 보내는 객체에는 두 가지가 포함됩니다. 암호화된 페이로드와 래핑된 DEK입니다. 그 셋업은 필드별 제어보다 페이로드 크기와 키 순환이 더 중요할 때 엔벨로프 암호화를 좋은 선택으로 만듭니다.

보안 범위

엔벨로프 암호화는 애플리케이션 계층에서 데이터를 보호합니다. 그래서 TLS가 끝난 뒤에도 페이로드가 로그, 큐, 백업 같은 곳에서 보호된 상태를 유지합니다.

무시할 수 없는 한 가지 한계가 있습니다. AI 추론 중에 데이터는 여전히 메모리에서 복호화되어야 합니다. 엔벨로프 암호화를 TEE 같은 컨피덴셜 컴퓨팅과 결합하지 않는 한, GPU나 CPU 메모리에 평문이 존재하는 창이 여전히 있습니다 ^[3][7]. 그것이 트레이드오프입니다. 큰 이점은 대규모 데이터를 다루면서 키가 바뀔 때마다 방대한 양을 다시 암호화하고 싶지 않을 때 나타납니다.

성능 영향

엔벨로프 암호화는 직접적인 비대칭 암호화보다 훨씬 실용적입니다. 왜일까요? AES-GCM 이 페이로드의 무거운 작업을 처리하고, 비대칭 암호는 작은 DEK만 보호하기 때문입니다.

그 셋업은 일부 환경에서 약 3%에서 7%의 오버헤드 를 더합니다 ^[5].

고해상도 이미지나 영상을 처리하는 멀티모달 AI API의 경우, AES-GCM은 인증 암호화, 즉 AEAD 를 제공하므로 강력한 선택입니다. 요컨대, 페이로드가 전송 중 변경되지 않았음을 확인하는 데 도움이 됩니다 ^[4].

키 관리

바로 여기서 엔벨로프 암호화가 빛을 발합니다. AI 학습 코퍼스는 테라바이트나 심지어 페타바이트 까지 커질 수 있습니다 ^[2]. 키가 바뀔 때마다 전체 데이터셋을 다시 암호화하는 것은 가혹한 운영 작업이 될 것입니다.

엔벨로프 암호화를 사용하면 페이로드를 건드리지 않습니다. 작은 DEK를 새 KEK로 다시 래핑하기만 하면 됩니다 ^[2].

여기서 중요한 몇 가지 기본 규칙이 있습니다.

• KEK를 애플리케이션 환경 변수가 아니라 클라우드 네이티브 KMS 나 HSM 에 저장하세요.
• 장기 레코드에 버전 메타데이터를 추가하여 키 변경 이후에도 오래된 데이터를 복호화할 수 있게 하세요 ^[1].

최적 AI API 사용 사례

엔벨로프 암호화는 대용량 페이로드, 멀티 테넌트 격리, 그리고 키 순환을 온전하게 유지해야 하는 장기 저장 데이터에 잘 작동합니다. 페이로드가 크거나, 오래 저장되거나, 재처리에 비용이 많이 든다면 이 패턴이 보통 합리적입니다.

배포 시나리오별 장단점

모든 경우에 맞는 단 하나의 암호화 방식은 없습니다. 올바른 선택은 무엇을 보호하는지(텍스트, 이미지, 오디오, 영상, 규제 메타데이터), 그 데이터가 어디로 이동하는지, 그리고 얼마나 많은 지연 시간을 감당할 수 있는지 에 달려 있습니다. 아래 매트릭스는 앞 섹션과 같은 관점을 사용합니다. 범위, 지연 시간, 키 관리, 그리고 종료 이후에도 보호가 유지되는지 여부입니다.

이 표는 앞의 방식별 비교를 배포 선택으로 바꿉니다.

이러한 시나리오는 한 가지를 분명히 합니다. 전송 보안에는 멈추는 지점이 있고, 애플리케이션 계층 보호는 전송이 끝나는 곳에서 시작됩니다.

데이터가 신뢰 경계 안에 머물고 TLS 종료 이후 보호가 필요하지 않을 때만 전송 전용 보호를 사용하세요. TLS가 끝나면, 평문이 이를 처리하는 서비스에 도달합니다. 그것이 애플리케이션 계층 암호화가 메우려는 공백입니다.

규제 멀티모달 워크로드의 경우, 기본 스택은 보통 이렇습니다.

• 전송에는 TLS 1.3
• 신원에는 mTLS
• 종료 이후에도 보호되어야 하는 데이터에는 필드 수준 또는 엔벨로프 암호화

그 계층화된 스택이 규제 AI API를 위한 실용적인 기본값입니다.

모델이 필드의 원시 값 자체가 아니라 컨텍스트를 필요로 할 때는 암호화가 아니라 마스킹을 사용하세요. 마스킹은 의미를 유지합니다. 암호화는 이를 제거합니다. 예를 들어 [email protected] 을 [EMAIL] 로 바꾸면, 모델이 실제 주소를 결코 보지 않고도 문장을 올바르게 읽을 수 있습니다.

결론

단 하나의 암호화 방식이 모든 것을 해내지는 못합니다. 선택은 범위, 지연 시간, 그리고 한 가지 단순한 질문으로 귀결됩니다. TLS가 끝난 뒤 데이터가 여전히 노출되는 곳은 어디인가? 실제로 그 결정은 전송, 신원, 페이로드 보호라는 세 레이어로 나뉩니다.

TLS 1.3은 AI API를 위한 기본 전송 레이어입니다. TLS 1.2는 레거시 시스템을 위한 폴백으로만 사용해야 합니다. 거기서부터 다른 방식들이 TLS가 남기는 공백을 메우러 들어옵니다. 하이브리드 암호화는 대량 암호화를 늦추지 않으면서 키 배포를 해결하기 때문에 애플리케이션 계층에서 가장 실용적인 모델입니다. 기계 신원을 검증하려면 mTLS를 사용하세요. 그런 다음 TLS가 끝난 뒤에도 보호되어야 하는 데이터에는 필드 수준 또는 엔벨로프 암호화를 사용하세요. 엔벨로프 암호화는 KEK를 순환하면 페타바이트의 데이터를 다시 암호화하지 않아도 되므로 대규모 AI 워크로드에 특히 유용합니다 ^[2].

이 레이어들을 함께 모으면, 전체 요청 경로를 보호합니다. 고보안 배포에서 계층화는 선택이 아닙니다. TLS가 전송을 처리하고, mTLS가 신원을 처리하며, 필드 수준 또는 엔벨로프 암호화가 TLS 종료 이후에도 안전하게 유지되어야 하는 데이터를 보호합니다.

자주 묻는 질문

TLS 1.3만으로 충분하지 않은 때는 언제인가요?

TLS 1.3은 데이터가 시스템 사이를 이동하는 동안 보호하는 데 도움이 됩니다. 하지만 그 보호는 서버 경계에서 멈춥니다.

데이터가 AI 서버에 도달하면, 모델이 처리할 수 있도록 복호화되어야 합니다. 그리고 이는 공백을 만듭니다. 데이터가 그때 메모리, 로그, 또는 캐시에서 노출될 수 있습니다.

그래서 데이터가 전송을 넘어 보호가 필요할 때는 TLS 1.3만으로는 충분하지 않습니다.

또한 몇 가지 다른 문제도 처리하지 못합니다.

• 전체 페이로드 수명 주기에 걸친 데이터 무결성
• 누가 데이터를 처리하는지 알 수 있는 연산 당사자의 진위성
• 양자 기반 공격에 대한 장기 보호

그래서 더 엄격한 통제가 필요하다면, 페이로드 수준 암호화 와 서명된 토큰 같은 추가 레이어를 TLS 1.3 위에 두고 싶을 것입니다.

모든 AI API에 mTLS를 써야 하나요?

항상 그렇지는 않습니다. 모든 AI API에 mTLS 를 써야 하는지는 보안 요구 사항과 셋업이 감당할 수 있는 복잡도에 달려 있습니다.

고가치 연결에 가장 합리적입니다. 여기에는 내부 서비스 간 트래픽, 관리자 API, 민감한 데이터가 관련된 전송이 포함됩니다. 많은 경우 계층적 셋업이 가장 좋습니다. 일반 트래픽에는 표준 TLS 1.3 을 쓰고, 민감한 경로에만 mTLS 를 요구하세요.

필드 수준 암호화와 엔벨로프 암호화 사이에서 어떻게 선택하나요?

API 토큰이나 개인 식별자처럼 특정 민감한 값에 대한 엄격한 보호가 필요할 때 필드 수준 암호화를 선택하세요. 그 값들이 로그, 캐시, 백업에 나타나더라도 암호화된 상태를 유지합니다. 이는 침해로 인한 피해를 제한하는 데 도움이 되고 규정 준수 요구를 지원할 수 있습니다.

더 큰 페이로드에 대한 효율적인 보호가 필요할 때 엔벨로프 암호화를 선택하세요. 데이터를 DEK로 암호화한 다음, 그 키를 KEK로 래핑합니다. 이 셋업은 키 순환과 키 관리를 더 쉽게 만듭니다.