암호화 개념

고수준 흐름

• 마스터 키는 사용자의 클라우드에서 관리되며 OpenAI는 해당 키를 직접 확인하지 않습니다.

• 사용자의 마스터 키는 OpenAI가 사용하는 데이터 암호화 키(DEK)를 암호화하는 데 사용됩니다.

• OpenAI는 저장된 데이터를 암호화하기 위해 DEK를 사용합니다 DEK는 사용자의 마스터 키로 암호화되어 eDEK(암호화된 DEK)가 생성되며, 이는 데이터와 함께 저장됩니다.

• 데이터를 읽을 때 OpenAI는 eDEK를 가져와 사용자의 KMS에 복호화를 요청해 DEK로 변환한 뒤 해당 키로 데이터를 복호화합니다.

EKM 암호화는 어떻게 작동하나요?

자세한 내용은 OpenAI 엔터프라이즈 키 관리(EKM) 개요 문서를 참고하세요.

OpenAI는 DEK를 저장하나요?

아니요. OpenAI는 사용자의 KMS에서 생성된 암호화된 DEK(eDEK)만 저장합니다. 데이터를 복호화할 때는 사용자의 KMS에 eDEK를 DEK로 복호화해 달라고 요청합니다.

OpenAI는 DEK를 캐시하나요?

예, 메모리에서만 캐시합니다. 이는 매번 데이터 암호화 또는 복호화 요청마다 KMS를 호출하지 않도록 하여 성능을 개선하기 위한 것입니다. DEK는 스토리지에 기록되지 않습니다.

클라우드 권한

OpenAI는 KMS에서 어떤 권한을 가지게 되나요?

사용자가 설정한 정책을 통해 부여한 권한만 갖습니다. 최소한 암호화 및 복호화 권한이 필요합니다. 기존 운영 용도로 사용 중인 키를 재사용하지 말고 OpenAI 전용으로 새로운 KMS 키를 생성하세요.

OpenAI는 언제 KMS 접근 권한을 갖게 되나요?

다음 단계가 모두 완료되어야 합니다. 1. OpenAI의 아이덴티티를 신뢰 정책 또는 워크로드 아이덴티티 등으로 인식, 2. KMS 접근 정책 생성, 3. 해당 정책에 OpenAI 아이덴티티에 대한 접근 권한 부여 이 모든 단계를 완료하지 않고 KMS만 생성한 경우 OpenAI는 접근할 수 없습니다.

마스터 키를 반드시 클라우드에 저장해야 하나요?

아니요. 마스터 키 관리 방식은 사용자가 선택할 수 있습니다. 클라우드에서 관리되는 방식이나 외부에 별도로 저장하는 방식 모두 사용할 수 있습니다. OpenAI는 KMS의 암호화 및 복호화 작업만 호출하면 되며, 마스터 키가 실제로 어떻게 이를 수행하는지는 OpenAI에 공개되지 않는 구현 세부 사항입니다.

키 수명 주기

DEK/eDEK 교체(OpenAI에서 관리)

DEK/eDEK는 얼마나 자주 교체되나요?

암호화 경로에서는 24시간마다(DEK/eDEK 키 쌍 요청 시)

복호화 경로에서는 1시간마다(DEK -> eDEK)

DEK가 변경될 때 사용자가 해야 할 작업이 있나요?

아니요. DEK/eDEK 교체는 OpenAI 내부에서 처리됩니다. 마스터 키가 유효한 한 해당 키로 암호화된 eDEK는 계속 DEK로 복호화될 수 있으며, 이를 통해 데이터 복호화가 가능합니다.

마스터 키 교체 및 폐기(사용자 관리)

키 교체와 키 폐기는 얼마나 자주 이루어지나요?

OpenAI는 마스터 키를 확인할 수 없으므로 이는 사용자가 결정합니다

키 교체와 키 폐기의 차이는 무엇인가요?

키 폐기는 기존 키로 암호화된 데이터에 대한 접근을 차단합니다. 키 교체는 새로운 키로 데이터를 암호화하면서도 기존 데이터에 대한 읽기 접근은 유지합니다.

마스터 키를 폐기하면 어떻게 되나요?

키가 폐기되거나 권한이 제거되면 캐시된 키가 만료된 이후 워크스페이스는 결국 정상적으로 작동하지 않게 됩니다. 이 시점 이후에는 OpenAI가 저장된 데이터를 복호화하거나 새로운 데이터를 암호화할 수 없습니다. 결과적으로 데이터는 '완전히 파기된 것과 같은 상태'가 됩니다.

키 폐기는 얼마나 빠르게 적용되나요?

OpenAI는 성능과 안정성을 위해 DEK를 메모리에 캐시합니다. 키 폐기는 일반적으로 캐시된 키가 만료되고 재검증이 실패하면 1시간 이내에 적용됩니다.

키 폐기를 안전하게 테스트할 수 있나요?

운영 워크스페이스에서 키 폐기를 테스트하는 것은 기존 데이터에 영구적으로 접근할 수 없게 되므로 권장되지 않습니다. 그러나 고객은 올바른 동작을 확인하고 신뢰 가정을 검증하기 위해 샌드박스 환경에서 키 폐기를 테스트할 수 있으며, 그렇게 하는 것이 바람직합니다.

키가 영구적으로 폐기된 경우, 새로운 키를 연결하여 워크스페이스를 복구할 수 있나요?

아니요. 키가 손실되면 설계상 데이터는 복구할 수 없습니다. 유일한 해결 방법은 새로운 워크스페이스를 생성하는 것입니다.

키 변경으로 인해 워크스페이스에 접근할 수 없게 되면 어떻게 해야 하나요?

권장되는 대응 방법은 새로운 워크스페이스를 생성하는 것입니다. KMS를 업데이트해도 기존 데이터는 복구되지 않습니다.

CMEK 사용을 중단하려는 경우 롤백 계획은 어떻게 되나요?

현재로서는 롤백 계획이 없습니다. 워크스페이스가 CMEK으로 생성되면 모든 관련 데이터는 고객 관리 키로 암호화되며 해당 키 없이는 접근할 수 없습니다. CMEK 사용을 중단하는 유일한 방법은 새로운 워크스페이스를 생성하는 것이며, 기존에 암호화된 데이터는 영구적으로 접근할 수 없는 상태로 남게 됩니다.

마스터 키를 교체하면 어떤 일이 발생하나요?

암호화를 위해 새로운 암호화 키(암호화 재료)가 생성되며, 이후의 암호화 요청에는 새로운 키가 사용됩니다. 그러나 KMS 식별자(ARN 또는 키 이름)는 동일하게 유지되며 기존 데이터는 계속 복호화할 수 있습니다. 많은 클라우드 제공업체(AWS, GCP, Azure)는 자동 키 교체 기능을 제공합니다.

OpenAI는 마스터 키를 교체하면 기존 데이터도 다시 암호화하나요?

아니요. 새로운 암호화 키(암호화 재료)는 새로 생성되는 데이터의 암호화에만 사용됩니다.

키 교체 또는 키 폐기가 적용되기까지 얼마나 걸리나요?

1시간입니다. 이는 DEK/eDEK가 메모리에 캐시되며 OpenAI가 이를 매시간 KMS를 통해 재검증하기 때문입니다.

KMS 식별자 변경

KMS 식별자 변경은 키 폐기인가요, 키 교체인가요?

키 폐기입니다. 하나의 키는 다른 키로 암호화된 데이터를 복호화할 수 없습니다.

ChatGPT 워크스페이스의 KMS 식별자 변경을 OpenAI가 도와줄 수 있나요?

키를 폐기하려는 의도임을 확인해 주시면 ChatGPT 워크스페이스에 대해 해당 작업을 도와드릴 수 있습니다. 참고로 KMS ARN이 업데이트되면 기존 데이터는 접근할 수 없는 상태로 유지되므로, 변경 이후에는 접근 가능한 데이터와 불가능한 데이터가 혼재된 상태가 됩니다.

API 프로젝트의 KMS 식별자 변경을 OpenAI가 도와줄 수 있나요?

API를 사용하는 경우 프로젝트를 아카이브하고 새로 생성하는 것이 용이하므로, 이미 데이터에 접근할 수 없는 프로젝트를 아카이브하고 OpenAI에 새로운 EKM 구성을 등록한 뒤 새로운 KMS 키로 새로운 API 프로젝트를 생성하시기 바랍니다.

KMS 식별자를 직접 정기적으로 변경하려면 어떻게 해야 하나요?

키를 정기적으로 폐기하는 상황은 일반적이지 않으므로 이는 권장되지 않습니다. 다만 KMS 키 별칭을 지원하는 클라우드 제공업체(AWS 등)를 사용하는 경우에는 가능합니다. 해당 KMS 키 별칭을 OpenAI에 등록한 후, 클라우드 제공업체에서 별칭이 가리키는 기본 KMS 식별자를 언제든지 교체하여 키 폐기를 수행할 수 있습니다.

베타와 GA 동작 비교

암호화 베타를 운영 환경에서 사용할 때 알려진 위험이나 시스템 수준 변경 사항이 있나요?

베타 환경은 기능적으로 GA와 동일하며 별도의 마이그레이션 단계는 필요하지 않습니다. 주요 위험은 일부 예외적인 기능이 아직 완전히 구현되지 않아 암호화된 콘텐츠를 지원하지 않을 수 있다는 점입니다. 이러한 문제는 드물지만 현재 적극적으로 해결하고 있습니다. 이러한 잠재적 문제와 관계없이 데이터는 완전히 암호화되어 보호됩니다.

베타에서 GA로 전환할 때 별도의 마이그레이션 단계가 있나요?

아니요. 암호화 베타를 사용하는 워크스페이스는 사용자 조치 없이 GA에서 자동으로 지원됩니다.

추가 기술 세부 정보

봉투 암호화 및 권한

EKM 사용을 위해 OpenAI에 GenerateDataKey 권한을 부여해야 하나요?

아니요. OpenAI는 KMS 키에 대해 Encrypt 및 Decrypt 권한만 필요로 합니다. GenerateDataKey 권한은 EKM 통합에 필요하지 않습니다.

OpenAI는 고객 데이터에 봉투 암호화를 사용하나요?

예. OpenAI는 봉투 암호화 모델을 사용합니다.

• 고객 KMS: 키 암호화 키(KEK)를 관리합니다. OpenAI는 KEK를 확인하거나 저장하지 않습니다.

• OpenAI 인프라: 데이터 암호화 키(DEK)를 생성하고 관리합니다. 각 DEK는 저장되기 전에 사용자의 KEK로 암호화(래핑)됩니다.

• 데이터 흐름:

  • 고객 데이터는 DEK로 암호화됩니다.

  • 해당 DEK는 KEK로 암호화되어 eDEK가 생성됩니다.

  • eDEK는 암호화된 데이터와 함께 저장됩니다.

  • 데이터를 복호화할 때 OpenAI는 KMS에 eDEK 복호화를 요청하여 DEK를 얻고 이를 사용해 콘텐츠를 복호화합니다.

왜 OpenAI는 KMS가 KEK와 DEK를 모두 관리하도록 하는 대신 이 모델을 선택했나요?

일반적으로 사용되는 봉투 암호화 방식은 두 가지입니다.

KMS 관리 KEK 및 DEK:

장점: 구현이 단순하며 별도의 암호화 인프라를 유지할 필요가 없습니다.

단점: 모든 암호화 및 복호화 요청이 KMS를 거치므로 지연 시간과 비용이 증가하고 단일 장애 지점이 발생합니다.

KMS 관리 KEK / OpenAI 관리 DEK(당사 방식):

장점: 지연 시간과 비용이 크게 줄어들고 확장성과 안정성이 향상되며, KMS 일부 장애 발생 시에도(DEK 캐시 TTL 범위 내에서) 운영을 지속할 수 있습니다.

단점: OpenAI 측 구현이 다소 복잡합니다.

이 설계는 강력한 보안을 제공하면서 고객의 운영 위험과 비용을 최소화할 수 있도록 합니다.

DEK는 얼마나 자주 교체되나요?

각 DEK는 약 60분마다 교체됩니다. 이로 인해 시간 기반 격리가 제공되며, DEK가 손상되더라도 영향은 해당 1시간 동안 암호화된 데이터로 제한됩니다.

KMS 요청량 및 관측 가능성

사용자 메시지 수에 비해 KMS 요청 수가 훨씬 적게 보입니다. 이 수치는 일치해야 하나요?

아니요, 두 수치는 직접적으로 일치하지 않습니다.

OpenAI는 성능을 위해 DEK를 메모리에 캐시하므로 KMS 호출은 모든 암호화 및 복호화 작업마다 발생하지 않고 DEK를 복호화해야 할 때만 발생합니다. 따라서 다음과 같은 상황이 발생합니다.

• 사용자 상호작용 수보다 적은 KMS 요청 수

• 캐시된 DEK가 만료될 때(약 1시간마다) 또는 오래된 암호화 데이터를 조회할 때 간헐적인 요청이 증가합니다.

• 사용자가 장시간 이어진 대화를 계속할 때처럼 과거 데이터를 조회하면서 이전 DEK를 불러와야 하는 경우 추가 호출이 발생합니다.

KMS 요청 수는 캐시 상태, 사용자 행동, 데이터 접근 패턴, 대화 길이에 따라 달라지므로 메시지 수와 직접적으로 일치하지 않습니다.