B 고급 보안 TDE(투명한 데이터 암호화)로 OKM 사용

이 부록은 TDE(투명한 데이터 암호화)로 OKM을 사용하여 민감한 데이터베이스 정보의 암호화 및 해독을 관리하는 방법에 대해 설명합니다. 이 솔루션에서는 Oracle StorageTek 테이프 드라이브에 사용된 것과 동일한 암호화 기술을 사용하여 Oracle 데이터베이스에 대한 암호화 키를 관리할 수 있습니다.

Oracle Database 11gR2의 한 가지 기능인 투명한 데이터 암호화는 다음에 대한 데이터베이스 암호화 및 해독 서비스를 제공합니다.

Oracle 데이터베이스 제품
Oracle RAC(Oracle Real Application Clusters)
Oracle Data Guard
Oracle Exadata 데이터베이스 시스템
Oracle Recovery Manager(RMAN)
Oracle Data Pump

이 부록에서는 사용자가 TDE에 익숙하다고 가정합니다. 다음 URL에서 제공되는 Oracle Advanced Security Transparent Data Encryption Best Practices 문서를 참조하십시오.

http://www.oracle.com/us/products/database/twp-transparent-data-encryption-bes-130696.pdf

TDE(투명한 데이터 암호화) 개요

도표B-1은 TDE(투명한 데이터 암호화)로 Oracle 데이터베이스를 제공하는 OKM 클러스터를 보여줍니다. OKM 클러스터의 기본 구성 요소에 대한 자세한 내용은 장1, "소개"를 참조하십시오.

도표 B-1 TDE가 사용되는 OKM 클러스터

TDE는 TDE 열 암호화 및 TDE 테이블스페이스 암호화를 위한 2계층 키 접근 방식을 사용하여 암호화 서비스를 제공합니다. 마스터 암호화 키는 첫번째 계층에서 데이터베이스 내에 저장된 두번째 계층 테이블 또는 테이블스페이스 데이터 암호화 키를 암호화하기 위해 사용됩니다.

TDE는 마스터 암호화 키를 외부 보안 모듈(Oracle Wallet 또는 HSM)에 저장합니다. 이는 권장되는 보안 방식이며 여러 가지 위협으로부터 최상의 보안 레벨을 유지 관리하는 데 중요합니다. TDE 마스터 암호화 키의 보안 스토리지를 위해서는 OKM을 사용하는 것이 좋습니다.

OKM을 사용하도록 TDE가 구성된 경우 OKM은 AES256 마스터 암호화 키를 만들고 이를 안전하게 보호합니다. OKM은 복제(클러스터 내에 여러 복사본 생성) 및 OKM 자체 백업을 통해 키를 보호합니다.

재해 복구 계획에 대한 자세한 내용은 OKM Disaster Recovery Guide를 참조하십시오.

OKM의 PKCS#11 공급자

PKCS#11 공급자는 Oracle Solaris 및 Oracle Linux에서 사용할 수 있으며 OKM에서 TDE를 사용하도록 인증되었습니다. 이 공급자를 "pkcs11_kms"라고 부릅니다. TDE는 HSM(하드웨어 보안 모듈)에 대한 내장 지원을 통해 pkcs11_kms 공급자를 사용하도록 구성할 수 있습니다.

pkcs11_kms 공급자는 OKM과 상호 작용하여 키 만들기 및 키 검색 작업을 수행합니다. PKCS#11 소비자 응용 프로그램(예: TDE)은 pkcs11_kms 공급자를 사용하여 암호화 및 해독 기능에 사용할 키를 획득할 수 있습니다. 이러한 응용 프로그램은 응용 프로그램에서 정의되는 레이블을 사용하여 키 객체를 식별합니다. TDE는 마스터 키가 만들어질 때 이 레이블을 생성합니다. pkcs11_kms 공급자는 이 레이블을 OKM으로 전달하며, 이 레이블은 데이터 장치에서 메타 데이터로 유지 관리됩니다. OKM에서 키는 데이터 장치와 연관되며, pkcs11_kms 공급자에 대해 이 관계는 항상 1:1입니다. 새 마스터 키가 생성될 때마다 키 레이블이 포함된 데이터 장치가 해당 키 객체와 함께 생성됩니다.

자세한 내용은 "OKM에서 TDE 마스터 키 찾기"를 참조하십시오.

OKM에서 TDE 인증

OKM과 상호 작용하는 모든 엔티티는 로그인하는 관리 사용자, 키 자료를 검색하는 테이프 드라이브, Oracle TDE와 같은 PKCS#11 소비자든 간에 인증을 거쳐야 합니다.

TDE는 pkcs11_kms 공급자를 사용하도록 구성된 특정 토큰을 통해 OKM에서 인증됩니다. 이 토큰은 특히 Oracle 데이터베이스 인스턴스 및 OKM 클러스터 노드와 같이 세션의 각 당사자에 대한 상호 인증을 위해 암호 기반 인증 및 X.509 인증서를 사용합니다. 이러한 자격 증명을 PKCS#11 토큰에 올바르게 전달하도록 TDE를 구성해야 합니다.

구성 지침은 이 부록의 시작 부분에서 참조되는 Oracle Advanced Security Transparent Data Encryption Best Practices 문서를 참조하십시오.

인증 자격 증명 관리

OKM에서는 pkcs11_kms 공급자를 사용하는 에이전트에 대한 인증 자격 증명을 관리할 수 있습니다. 에이전트 문장암호를 재설정하고, 정책에 따라 에이전트를 사용 또는 사용 안함으로 설정하거나 삭제할 수 있습니다.

보안 위반이 검색되면 키 검색이 거부되도록 특정 에이전트를 사용 안함으로 설정하고, 다른 응용 프로그램 또는 장치를 제공하는 다른 에이전트는 액세스가 유지되도록 허용할 수 있습니다.

에이전트 문장암호를 재설정할 경우에는 pkcs11_kms 공급자가 해당 슬롯 구성을 저장하는 디렉토리에서 프로파일 디렉토리를 제거합니다(예: KMSTOKEN_DIR 디렉토리로 식별되는 위치).

로드 균형 조정 및 페일오버

pkcs11_kms 공급자는 OKM 클러스터 서비스, 로드 밸런서 및 클러스터 페일오버 논리를 사용하여 OKM 클러스터를 인식합니다. pkcs11_kms 공급자는 클러스터 검색 작업을 주기적으로 실행하여 OKM 클러스터에 대한 클라이언트측 인식을 투명하게 유지 관리합니다. 네트워크 변경 사항 및 OKM 클러스터 또는 KMA 가용성에 대한 변경 사항은 pkcs11_kms 공급자 및 TDE를 대신하여 에이전트에 의해 처리됩니다. PKCS#11 키 생성 및 키 검색 작업은 OKM 클러스터의 KMA에서 로드 균형이 조정됩니다.

키 검색 성능을 더욱 최적화하기 위해서는 OKM 사이트를 사용하여 KMA와 연관되도록 에이전트를 구성할 수 있습니다. 이 기능을 사용하면 네트워크 토폴로지에 따라 사이트를 정의할 수 있습니다. 일반적으로 사이트 내의 KMA 및 에이전트는 WAN 상의 멤버 KMA 및 에이전트와 반대로 네트워크 대기 시간이 낮습니다.

네트워크 세그먼트 또는 KMA를 사용할 수 없으면 에이전트 내부의 페일오버 논리가 작업을 완료하기 위해 다른 KMA를 선택합니다. TDE는 페일오버를 인식하지 못하므로 키 관리 작업이 매우 안정적입니다. 페일오버는 에이전트와 동일한 사이트 내에서 KMA의 환경 설정을 지정합니다.

kmscfg(1M) 유틸리티를 사용하면 검색 빈도 및 에이전트의 페일오버 등록 정보를 조정할 수 있습니다. 자세한 내용은 kmscfg 매뉴얼 페이지를 참조하십시오.

계획 고려 사항

다음과 같은 여러 계획 주제에 대해 설명합니다.

Oracle 데이터베이스 고려 사항
OKM 성능 및 가용성 고려 사항
재해 복구 계획
네트워크 계획
키 관리 계획

Oracle 데이터베이스 고려 사항

OKM은 다음과 같은 Oracle 데이터베이스 구성과 호환됩니다.

단일 인스턴스, Oracle RAC One Node
Oracle 데이터베이스 고가용성 아키텍처
- Oracle RAC
  
  Oracle RAC(Oracle Real Application Clusters)가 포함된 Oracle 데이터베이스는 OKM에서 인증되었습니다. Oracle RAC 시스템의 각 노드에는 TDE에서 사용하도록 구성된 pkcs11_kms 공급자가 필요합니다. 모든 노드는 인증을 위해 동일한 OKM 에이전트 ID를 공유해야 합니다. Oracle RAC에서 네트워크 토폴로지는 공개 및 개인 네트워크를 사용합니다. Oracle RAC 노드-노드 트래픽에 사용되는 개인 네트워크는 키 검색 트래픽을 더 효과적으로 격리시키기 위해 OKM 서비스 네트워크와 공유될 수 있습니다. 이러한 개인 네트워크의 구성 방법에 따라 원격 사이트의 KMA와 같이 개인 네트워크 외부에서 KMA에 대한 에이전트 페일오버를 수행하지 못할 수 있습니다.
  
  Oracle RAC 및 pkcs11_kms 공급자 구성 파일의 공유 스토리지 요구 사항에 대한 자세한 내용은 "OKM과 TDE 통합"을 참조하십시오.
- Oracle RAC 확장 클러스터
  
  이 구성에서는 검색 시간을 최소화하기 위해 OKM 클러스터 내의 KMA가 Oracle RAC 노드와 함께 네트워크에 배치되어야 합니다.
- Oracle Exadata 데이터베이스 시스템
  
  위의 "Oracle RAC"를 참조하십시오.
Oracle Data Guard

모든 보조 데이터베이스는 기본 데이터베이스에서 사용되는 것과 동일한 OKM 클러스터에 액세스합니다.
다중 데이터베이스 인스턴스

호스트에서 여러 개의 독립 데이터베이스 인스턴스를 실행할 때는 PKCS#11 토큰이 각 인스턴스에 대해 구성되어 있어야 합니다. 이를 위해서는 각 데이터베이스 인스턴스에 대해 OKM 에이전트를 만들고 토큰을 통해 OKM에서 에이전트를 인증해야 합니다. 이 작업을 완료하려면 kmscfg 도구를 사용합니다.

동일한 O/S 사용자로 여러 데이터베이스 인스턴스를 실행하지만, 다른 OKM 에이전트를 사용할 경우에는 kmscfg 유틸리티를 호출할 때마다 KMSTOKEN_DIR 환경 변수를 다른 위치로 설정해야 합니다. kmscfg 유틸리티에 대한 자세한 내용은 "OKM의 TDE 구성"을 참조하십시오.

동일한 호스트에서 여러 데이터베이스를 실행하는 방법에 대한 자세한 내용은 이 부록의 시작 부분에서 참조되는 Oracle Advanced Security Transparent Data Encryption Best Practices 문서를 참조하십시오.
Oracle RMAN
Oracle Data Pump

OKM 성능 및 가용성 고려 사항

pkcs11_kms 토큰을 통한 TDE 키 검색은 일반적으로 KMA 액세스당 100 ~ 200밀리초가 걸립니다. 페일오버가 수행될 때 응답 시간은 여기에 페일오버 시도 횟수를 곱한 값이 됩니다.

OKM 백업 및 키 전송 작업은 리소스 소모가 높은 작업이며 OKM 데이터베이스 성능에 영향을 줄 수 있습니다. OKM 백업 수행 시간 및 위치를 결정할 때는 신중하게 계획하십시오.

OKM 백업은 클러스터 전체에서 수행되므로 Oracle 데이터베이스 인스턴스를 제공하지 않는 KMA에서 수행할 수 있습니다. 이와 비슷하게, 키 전송 작업도 클러스터 전체 작업이며 어떠한 KMA에서든 수행할 수 있습니다. 따라서 현재 Oracle 데이터베이스 인스턴스를 제공 중이 아닌 KMA를 선택하는 것이 좋습니다.

재해 복구 계획

OKM 재해 복구 계획에 대한 자세한 내용은 Oracle 데이터베이스 설명서와 함께 OKM Disaster Recovery Guide를 참조하십시오.

재해 복구 계획 결정은 네트워크 계획 운용에 영향을 줍니다. pkcs11 공급자의 구성 디렉토리는 재해 복구 계획 시 새로운 고려 사항입니다. 특히 Oracle RAC의 노드 사이에 공유될 경우 pkcs11_kms 토큰을 다시 구성할 필요가 없도록 이 스토리지 영역에 대한 복구 시나리오를 고려하십시오.

네트워크 계획

OKM 클러스터 구성은 Oracle 데이터베이스 서버 및 기업의 재해 복구 전략에 맞게 계획해야 합니다. OKM 네트워킹 옵션은 매우 유동적이며 OKM 관리 및 서비스 네트워크에서 사용되는 다중 홈 인터페이스를 포함합니다. 자세한 내용은 OKM System Assurance Guide를 참조하십시오.

키 관리 계획

키 관리 계획은 키 수명 주기 및 기업의 보안 정책 문제를 해결해야 합니다. 이러한 고려 사항은 자연스럽게 데이터 보존에 대한 토론으로 이어집니다.

NIST SP-800 키 관리 단계 및 해당 OKM 키 상태에 대한 자세한 내용은 "상태 전환"을 참조하십시오.
키 정책이 충분히 긴 시간으로 설정되지 않았을 때 발생할 수 있는 문제에 대한 자세한 내용은 "OKM 정책 기반 키 만료로 인한 키 다시 입력"을 참조하십시오.

키 정책 고려 사항

모든 TDE 마스터 키는 OKM에서 생성되는 AES 256비트입니다. KMA는 Sun Crypto Accelerator 6000 PCIe 카드, FIPS 140-2 레벨 3 인증 HSM을 포함할 수 있습니다. KMA에 이 하드웨어 보안 모듈이 포함될 경우 해당 키는 HSM에 의해 생성됩니다. 그렇지 않으면 암호화 작업에 Solaris Crypto Framework의 소프트웨어 토큰 공급자가 사용됩니다. 자세한 내용은 "키 정책"을 참조하십시오.

키 수명 주기

키 수명 주기는 키 정책 계획 결정과 관련된 기본 구성 항목입니다. 키 수명 주기의 작업 단계에 대한 기간은 데이터 보존 요구 및 TDE 마스터 키를 다시 입력할 빈도에 따라 선택해야 합니다. 자세한 내용은 "키 수명 주기"를 참조하십시오.

주:

TDE의 DDL에서는 OKM 내의 스키마 암호화 대화 상자와 마찬가지로 마스터 키에 대해 여러 키 크기를 지정할 수 있습니다. OKM에서는 AES 256비트 키만 사용할 수 있습니다.

키 정책 암호화 기간

키 정책 암호화 기간은 수명 주기 중 보호 및 처리(암호화 및 해독) 상태에서 키를 사용할 기간을 정의합니다. 이 기간은 다시 키를 입력하기 전에 마스터 키를 사용할 수 있는 기간과 일치합니다(예: PCI의 경우 최대 1년).

키 정책 암호화 사용 기간

키 정책 암호화 사용 기간은 키 수명 주기의 처리 전용(해독 전용) 상태 중에 데이터를 해독하기 위해 마스터 키를 사용할 수 있도록 할당된 남은 시간입니다. 이 기간의 길이는 TDE 마스터 키로 보호되는 데이터에 대한 데이터 보존 요구 사항을 따라야 합니다. 일반적으로 이 값은 데이터 보존을 위한 기업 정책에 따라 년 수로 지정됩니다(예: 미국 납세 기록의 경우 7년의 보존 기간).

새 키가 생성되는 속도는 키를 다시 입력하는 작업이 거의 자주 수행되지 않으므로 TDE에서 문제가 되지 않습니다. 하지만 이것이 문제가 될 때는 키 정책에서 암호화 기간을 늘리고 키 다시 입력이 자주 수행되지 않도록 조정해야 합니다. 또한 KMA가 사용 가능한 키 풀을 더 크게 유지 관리할 수 있도록 OKM 키 풀 크기 구성 매개변수를 늘릴 수도 있습니다.

필요에 따라 여러 가지 유형의 데이터베이스에서 사용할 수 있도록 여러 키 정책을 정의할 수 있습니다.

키 그룹을 통한 키 액세스 제어

여러 가지 목적에 따라 여러 데이터베이스 인스턴스 또는 여러 에이전트가 OKM 클러스터에 액세스할 경우 OKM에서 관리되는 키에 대한 액세스를 제어해야 할 수 있습니다.

모든 OKM 에이전트에는 최소한 하나 이상의 키 그룹이 지정됩니다(기본 키 그룹 지정 필요). 이러한 키 그룹 지정에 따라 에이전트에는 해당 그룹 내에 있는 키에 액세스할 수 있는 권한이 부여됩니다. 에이전트의 기본 키 그룹은 pkcs11_kms 공급자의 에이전트가 키를 만들 수 있는 유일한 키 그룹입니다.

마스터 키를 데이터베이스 인스턴스 또는 호스트 사이에 공유할 필요가 없을 때는 다중 키 그룹 사용을 고려하십시오. 예를 들어, 격리가 보장되도록 운용 데이터베이스 인스턴스에 대해 하나의 키 그룹을 사용하고 개발/테스트 데이터베이스를 위해 다른 키 그룹을 사용할 수 있습니다. 그런 다음 테스트 데이터베이스 키 그룹에 있는 에이전트가 운용 데이터베이스의 마스터 키를 사용하려고 시도하면 OKM이 이러한 에이전트를 차단할 수 있습니다. 또한 이러한 시도는 OKM 감사 로그에 플래그 지정되며 운용 데이터베이스를 손상시킬 수도 있는 구성 오류를 나타낼 수 있습니다.

TDE는 또한 키 레이블 이름 지정 규칙을 통해 마스터 키 격리를 제공합니다. PKCS#11 사양에서 키 레이블은 고유할 필요가 없습니다. 하지만 OKM은 레이블 네임스페이스 범위가 OKM 클러스터에 대해 전역이 되도록 키 그룹에 관계없이 고유한 레이블을 강제 적용합니다. 서로 다른 데이터베이스 인스턴스의 서로 다른 마스터 키 사이에 레이블 충돌이 발생하면 항상 첫번째 생성된 레이블이 반환됩니다. 다른 키 그룹에 속하는 동일한 레이블을 공유하는 키에 액세스하려고 시도하는 에이전트는 OKM에서 거부됩니다. 이러한 에이전트는 키 다시 입력 작업 중에 검색되며 이를 임시로 해결하기 위해서는 또 다른 충돌하지 않는 레이블이 생성될 때까지 키를 다시 입력해야 합니다.

키 및 데이터 삭제 고려 사항

데이터 보존 요구 사항을 따르기 위한 데이터 삭제는 TDE 마스터 키 삭제로부터 시작할 수 있습니다. 키 삭제 방법 및 시간은 중요한 계획 항목입니다. OKM은 이러한 키를 포함하는 OKM 백업 추적 및 키 삭제를 위한 기능을 제공합니다. OKM 백업 관리는 재해 복구 계획 항목인 동시에 키 삭제 계획 항목이기도 합니다.

OKM과 TDE 통합

이 섹션에서는 TDE에 사용할 수 있도록 pkcs11_kms 및 OKM 클러스터를 설치 및 구성하는 방법에 대해 설명합니다.

시스템 요구 사항

TDE로 OKM을 사용할 때는 다음과 같은 최소 버전이 지원됩니다.

Oracle Key Manager

Replication Schema 버전 13으로 작동하는 Oracle Key Manager 2.4.1

GUI 및 CLI에 대해 지원되는 OKM 관리 플랫폼은 OKM 제품 릴리스 정보에 설명되어 있습니다. 여기에는 Oracle Solaris 및 Microsoft Windows 플랫폼에 대한 특정 고려 사항이 포함되어 있습니다.

pkcs11_kms

Oracle Solaris 11 Express 및 SRU 12
Oracle Solaris 11 pkcs11_kms, x86 또는 SPARC, 32비트 또는 64비트
Oracle Solaris 10 업데이트 10 x86용 pkcs11_kms 패치 147441-03 또는 SPARC, 32비트 또는 64비트용 패치 147159-02
OEL(Oracle Enterprise Linux) 릴리스 5.5
지원되는 pkcs11_kms 플랫폼의 Oracle Database 11.2.0.2 및 필수 패치 12626642

OKM 설치

OKM 클러스터 설치 프로세스는 OKM Installation Guide에서 설명합니다. 일반적으로 OKM 설치에는 계획, 설치 및 구성 서비스 선택을 돕기 위한 Oracle Professional Services 사용이 포함됩니다. 또한 보안 팀도 계획 프로세스에 참여하는 것이 좋습니다.

작동 가능한 OKM 클러스터를 설정한 후에는 이 부록의 구성 섹션에 설명된 OKM 관리 단계를 따릅니다.

pkcs11_kms 설치

OKM의 PKCS#11 공급자 pkcs11_kms를 Oracle 데이터베이스 서버에 설치하고 구성해야 합니다. pkcs11_kms 배포판은 다음과 같은 각 플랫폼에 대해 제공됩니다.

Oracle Solaris 11 또는 Solaris 11 Express
Oracle Solaris 10 업데이트 10
Oracle Enterprise Linux

Oracle Solaris 11 또는 Solaris 11 Express용 pkcs11_kms 설치

pkcs11_kms를 설치하려면 다음 단계를 수행합니다.

pkcs_kms 패키지의 버전을 표시합니다.
```
#> pkg info -r pkcs11_kms
```
이 명령의 출력을 확인합니다.
Solaris 11의 경우 다음 명령을 입력합니다.
```
#> pkg install system/library/security/pkcs11_kms
```
Solaris 11 Express의 경우 다음 명령을 입력합니다.
```
#> pkg install system/library/security/crypto/pkcs11_kms 
```
공급자를 Solaris Crypto Framework에 설치합니다.
```
# cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
```
주:
작은 따옴표(')가 중요합니다. cryptoadm(1M)을 참조하십시오.
다음 명령 시퀀스를 입력하여 설치를 확인합니다.
```
# cryptoadm list -m -v \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
```
주:
이 명령을 실행하면 Kmscfg가 실행될 때까지 'no slots presented' 메시지가 표시됩니다.

Oracle Solaris 10 업데이트 10용 pkcs11_kms 설치

pkcs 배포판은 Solaris 10 업데이트 10 설치에 "SUNWpkcs11kms"로 설치됩니다.

SPARC 시스템에는 Solaris 패치 147159-03 이상이 필요합니다.
x86 시스템에는 Solaris 패치 147441-03 이상이 필요합니다.

Solaris 패치를 다운로드하려면 다음 URL을 방문하십시오.

https://patchstatus.us.oracle.com/patchstatus/

pkcs11_kms를 설치하려면 다음 단계를 수행합니다.

다음 명령을 입력하여 하드웨어 플랫폼에 대해 pkcs11_kms 패키지를 설치합니다.
```
# pkgadd [-d path to parent dir of package] SUNWpkcs11kms
```
공급자를 Solaris Crypto Framework에 설치합니다.
```
# cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
```
주:
작은 따옴표(')가 중요합니다. cryptoadm(1M)을 참조하십시오.

Oracle Enterprise Linux용 pkcs11_kms 설치

pkcs11_kms는 다음 URL에서 My Oracle Support 사이트에 "패치" 13245560으로 배포됩니다.

http://www.myoraclesupport.com

로그인하고 Patches & Updates 탭을 누릅니다. 그런 후 이 특정 패치 ID를 직접 검색하거나 Oracle Key Manager 제품 및 Oracle Key Manager 2.5 릴리스를 검색합니다.

pkcs11_kms는 RPM 패키지로 배포됩니다. RPM 패키지 관리자 명령을 사용하여 이 소프트웨어를 설치합니다.

예를 들면 다음과 같습니다.

# rpm -i pkcs11kms-1.0.0-1.x86_64.rpm

pkcs11_kms 제거

다음 명령은 pkcs11_kms를 제거합니다.

Oracle Solaris 11용 pkcs11_kms 제거

pkcs11_kms를 제거하려면 다음 명령을 입력합니다.

# cryptoadm uninstall \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
# pkg uninstall system/library/security/pkcs11_kms

Oracle Solaris 10 업데이트 10용 pkcs11_kms 제거

pkcs11_kms를 제거하려면 다음 명령을 입력합니다.

# pkgrm SUNWpkcs11kms

Oracle Enterprise Linux용 pkcs11_kms 제거

Oracle 데이터베이스에 패키지화된 경우 pkcs11_kms 공급자는 Oracle 데이터베이스 제품을 제거할 때 사용되는 단계를 통해 제거됩니다. 다른 방법을 통해 설치된 경우에는 rpm을 사용하여 설치 절차를 역순으로 수행합니다.

예를 들면 다음과 같습니다.

# rpm -e pkcs11kms-1.0.0-1.x86_64.rpm

OKM의 TDE 구성

다음 섹션에서는 TDE 구성에 대해 설명합니다.

Oracle 데이터베이스 TDE 구성

각 Oracle 데이터베이스 서버는 지원되는 pkcs11_kms 플랫폼에서 11.2.0.2 이상을 실행해야 합니다. 필수 패치 12626642가 설치되어 있어야 합니다. 이 패치는 다음 URL에서 제공됩니다.

https://updates.oracle.com/download/12626642.html

설치 후에는 TDE 액세스를 지원하도록 공유 라이브러리 파일(pkcs_kms.so)을 구성해야 합니다. 라이브러리 경로는 OS마다 다릅니다.

/usr/lib/security/pkcs11_kms.so.1(Solaris만 해당, 32비트)
/usr/lib/security/amd64/pkcs11_kms.so.1(Solaris만 해당, 64비트)
/usr/lib64/pkcs11_kms.so.1(Linux만 해당, 64비트)

OKM 클러스터의 TDE 구성

다음 목록에서는 OKM 클러스터의 TDE 구성을 위해 필요한 작업을 요약하여 보여줍니다.

이러한 작업은 작동 중인 OKM 클러스터가 적합한 관리 사용자 및 역할로 구성되어 있다고 가정합니다.
OKM 클러스터의 모든 KMA는 최소한 OKM 2.4.1 및 복제 버전 13을 실행해야 합니다.

키 정책을 정의합니다.

다음을 참조하십시오.
- "키 정책"
- "키 정책 고려 사항".
그룹 정의를 정의합니다.

키 그룹에 키 정책을 지정하고 그룹에 대해 편리한 이름을 지정합니다.

다음을 참조하십시오.
- "키 그룹"
- "키 그룹을 통한 키 액세스 제어"
에이전트를 구성합니다.

다음을 참조하십시오.
- "OKM의 PKCS#11 공급자".
- "Agent List 메뉴"
각 에이전트를 기본 키 그룹과 연관시킵니다.

"Key Group Assignment to Agents 메뉴"를 참조하십시오.

에이전트 ID

에이전트 ID는 구성에 필요한 무엇이든 될 수 있으며, 데이터베이스 인스턴스를 에이전트와 연관시킬 수 있도록 Oracle 사용자와 일치해야 합니다.

문장암호

이 문장암호는 전자 지갑을 여는 DDL 문을 통해 OKM에서 인증을 수행할 수 있도록 Oracle 호스트에서도 구성되므로 강력한 문장암호를 선택하십시오(예: pkcs11_kms 토큰). 문장암호 요구 사항에 대한 자세한 내용은 "에이전트 만들기"를 참조하십시오.

공통 에이전트 ID를 공유하는 다중 Oracle RAC 노드에서 뿐만 아니라 TDE "전자 지갑"을 열어야 할 때마다 암호 기반 인증을 허용하려면 OneTimePassphrase 플래그를 "false"로 설정해야 합니다. 최대 보안을 위해서는 기본값인 "true"로 설정할 수 있지만 Oracle RAC가 아닌 단일 노드 Oracle 데이터베이스 구성에서만 작동합니다. OneTimePassphrase가 true이면 에이전트가 처음에 성공적으로 인증될 때만 에이전트의 X.509 인증서가 반환됩니다. pkcs11_kms 공급자는 문장암호로 보호되는 PKCS#12 파일에 X.509 인증서의 개인 키를 안전하게 저장합니다. 그런 다음 X.509 인증서 및 해당 개인 키가 OKM과의 에이전트 트랜잭션에 사용됩니다. pkcs11_kms 공급자가 저장하는 다른 정보에 대한 자세한 내용은 kmscfg(1M)를 참조하십시오.

키 그룹

TDE에 정의된 키 그룹에 에이전트를 지정합니다. pkcs11_kms 공급자는 키 다시 입력 작업을 비롯한 키 만들기 작업에 대해 기본 키 그룹만 지원합니다. 에이전트와 연관된 추가적인 비기본 키 그룹은 이러한 그룹의 키에서만 키 검색을 허용합니다. 이 기능은 마스터 키를 생성하지 않지만 마스터 키에 액세스하는 기능만 필요한 보조 데이터베이스의 지원과 같은 읽기 전용/해독 전용 데이터베이스 시나리오에서 활용될 수 있습니다.

pkcs11_kms의 TDE 구성

pkcs11_kms 공급자는 TDE 마스터 키가 필요한 Oracle 데이터베이스 노드에 구성되어 있어야 합니다. 다음 단계를 수행하여 pkcs11_kms 공급자를 구성합니다.

O/S 사용자 고려 사항:

Oracle 데이터베이스 사용자 계정을 사용하여 에이전트 및 pkcs11_kms 공급자를 구성합니다. 여기에는 O/S 사용자에 대한 특별한 권한이 필요하지 않습니다. 호스트에서 "다중 Oracle 홈"이 지원될 경우 pkcs11_kms 토큰 구성은 Oracle 데이터베이스 소프트웨어 소유자의 사용자 계정과 일치해야 합니다. 자세한 내용은 Oracle Database Installation Guide 11g Release 2를 참조하십시오.
kmscfg 유틸리티는 한 번에 하나씩 사용자당 슬롯 구성을 만듭니다. 개별 사용자의 경우 추가 슬롯 구성을 정의할 수 있지만 프로세스당 하나만 활성화됩니다.

주의:
KMS PKCS#11 공급자의 슬롯 구성 디렉토리에 대한 기본 위치는 Solaris 11 Express의 경우 /var/kms/$USER이고 Solaris 11 SRU5에서는 /var/user/$USER/kms입니다. Solaris 11 Express 시스템을 Solaris 11 SRU5로 업그레이드하려면 먼저 슬롯 구성을 다른 곳에 저장해야 합니다.
예를 들면 다음과 같습니다.

# cd /var/kms/$USER

# tar cvf ~/save_my_okm_config.tar .

업그레이드 후에는 슬롯 구성을 새 위치로 복원합니다. 예를 들면 다음과 같습니다.

# mkdir -p /var/user/$USER/kms

# cd /var/user/$USER/kms

# tar xvf ~/save_my_okm_config.tar

업그레이드하기 전에 pcks11_kms 데이터를 백업하지 않으면 데이터가 손실되고 암호화된 데이터에 대해 Oracle 데이터베이스에서 사용되는 마스터 키를 사용할 수 없게 됩니다.

kmscfg 유틸리티는 다음 경로 중 하나에서 KMS 구성 디렉토리에 구성 및 런타임 데이터를 저장합니다.
- /var/user/$USER/kms(Solaris 11)
- /var/kms/$USER(Solaris 10u10 및 Solaris 11 Express)
- /var/opt/kms/$USER(Oracle Enterprise Linux)
이 디렉토리는 $KMSTOKEN_DIR 환경 변수에 의해 고객이 선택한 위치로 대체됩니다.

kmscfg가 실행되면 "profile" 이름이 제공됩니다. 이 이름은 위에서 설명한 구성 디렉토리 내에 생성된 에이전트별 런타임 하위 디렉토리에 사용됩니다.
슬롯 구성의 기본 위치에 대한 자세한 내용은 kmscfg 매뉴얼 페이지를 참조하십시오. 슬롯 구성은 KMSTOKEN_DIR 환경 변수로 제어하여 대체 슬롯 구성 및 파일 시스템 위치를 정의할 수 있습니다.

에이전트 프로파일이 Oracle RAC 노드 사이에 공유되어야 하는 Oracle RAC의 경우, kmscfg가 적합한 공유 파일 시스템 경로를 사용해 프로파일을 만들 수 있도록 KMSTOKEN_DIR 환경 변수를 사용합니다. KMSTOKEN_DIR 환경 변수가 설정되었으면 데이터베이스가 PKCS#11 작업을 수행하기 전에 항상 설정되도록 셸 구성 파일(예: .bashrc)에서 셸에 대해 이 환경 변수가 지속적으로 설정되어 있어야 합니다.
슬롯 구성 및 런타임 정보를 위해 파일 시스템 스토리지 공간을 할당합니다. Oracle RAC를 사용하려면 각 Oracle RAC 노드 사용자가 읽기 및 쓰기를 수행할 수 있는 권한을 사용하여 공유 파일 시스템 위치에서 프로파일을 정의합니다.
각 에이전트 로그의 증가를 허용하도록 공간 요구 사항을 할당합니다. 로그 파일은 자동으로 생성되며, 문제 해결 시 유용하게 활용할 수 있습니다. KMSAgentLog.log 파일에서 소비되는 공간은 Solaris의 logadm(1M) 또는 Oracle Enterprise Linux의 logrotate(8)와 같은 도구를 사용하여 관리할 수 있습니다. 대부분의 구성에서는 각 에이전트의 프로파일 디렉토리에 10MB만 할당해도 충분합니다.
kmscfg 유틸리티를 사용하여 pkcs11_kms 공급자를 초기화합니다. 이 단계에서는 나중에 pkcs11_kms 토큰과 연관될 OKM 에이전트에 대한 프로파일을 정의합니다.
```
 # kmscfg 
 Profile Name: oracle
 Agent ID: oracle
 KMA IP Address: kma1
```
이제 pkcs11 슬롯이 정의되었으며, OKM에서 인증을 확인할 수 있습니다.
1. Solaris 시스템에서는 cryptoadm(1M) 명령을 사용하여 인증을 확인합니다. 다음 예제에서 플래그 필드에 CKF_LOGIN_REQUIRED가 표시됩니다. 이는 슬롯이 아직 인증 토큰을 사용하여 구성되지 않았음을 나타냅니다.
```
solaris> cryptoadm list -v \ 
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1' 
Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1 
Number of slots: 1  
Slot #1 
Description: Oracle Key Management System 
Manufacturer: Oracle Corporation 
PKCS#11 Version: 2.20 
Hardware Version: 0.0 
Firmware Version: 0.0 
Token Present: True 
Slot Flags: CKF_TOKEN_PRESENT 
Token Label: KMS 
Manufacturer ID: Oracle Corporation 
Model: 
Serial Number:
Hardware Version: 0.0
Firmware Version: 0.0
UTC Time:
PIN Min Length: 1
PIN Max Length: 256
Flags: CKF_LOGIN_REQUIRED
```
2. pkcs11_kms 토큰이 OKM 클러스터에서 인증을 수행할 수 있는지 확인합니다.
  
  이 예제에서는 Linux 플랫폼에서 사용할 수 없는 유틸리티인 Oracle Solaris pktool(1)이 사용됩니다.
```
solaris> pktool inittoken currlabel=KMS
Enter SO PIN:
Token KMS initialized.
```
  SO(security officer(보안 관리자)에 대한 PKCS#11 약어) 프롬프트는 이전 단계에서 에이전트를 만든 OKM 관리자가 설정한 대로 에이전트의 보안 문장암호에 대한 프롬프트입니다.
3. Solaris 시스템에서는 Solaris Crypto Framework cryptoadm(1M) 명령 또는 pktool(1) 유틸리티를 사용하여 토큰이 초기화되었는지 확인합니다. cryptoadm의 출력으로 표시되는 토큰 플래그는 이제 CKF_TOKEN_INITIALIZED입니다.
```
solaris> cryptoadm list -v \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
 Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1
 Number of slots: 1
 Slot #1
 Description: Oracle Key Management System
 Manufacturer: Oracle Corporation
 PKCS#11 Version: 2.20
 Hardware Version: 0.0
 Firmware Version: 0.0
 Token Present: True
 Slot Flags: CKF_TOKEN_PRESENT
 Token Label: KMS
 Manufacturer ID: Oracle Corporation
 Model:
 Serial Number:
 Hardware Version: 0.0
 Firmware Version: 0.0
 UTC Time:
 PIN Min Length: 1
 PIN Max Length: 256
 Flags: CKF_LOGIN_REQUIRED CKF_TOKEN_INITIALIZED
```
4. Solaris 시스템에서 pktool(1) 유틸리티를 사용하여 PKCS#11 표시 가능 토큰의 상태를 확인합니다.
```
glengoyne> pktool tokens
Flags: L=Login required  I=Initialized  X=User PIN expired  S=SO PIN expired
Slot ID  Slot Name     Token Name                  Flags
-------  ---------     ----------                  -----
1        Sun Crypto    Softtoken      Sun Software PKCS#11 softtoken
2        Oracle Key Management System              KMS  L
glengoyne>
```
  토큰에 대한 로그인이 여전히 필요함을 보여줍니다. pktool 출력에서 플래그의 의미는 다음과 같이 표시될 수 있습니다.
```
glengoyne> pktool tokens -h
Usage:
   pktool -?    (help and usage)
   pktool -f option_file
   pktool subcommand [options...]
```
  여기서 하위 명령은 다음과 같을 수 있습니다.
```
   tokens
   * flags shown as: L=Login required  I=Initialized  
     E=User PIN expired  S=SO PIN expired
glengoyne>
```
5. Solaris 시스템에서 pktool(1) 유틸리티를 사용하여 토큰에 로그인하고, kmscfg(1) 단계에서 지정된 OKM 클러스터의 KMA 및 에이전트에 대해 OKM 관리자가 만든 문장암호를 사용하여 인증을 수행합니다. 이 문장암호는 SO PIN 프롬프트에 제공됩니다.
```
glengoyne> pktool inittoken currlabel=KMS
Enter SO PIN:
Token KMS initialized.
```
6. Solaris 시스템에서 pktool(1) 유틸리티를 사용하여 토큰 상태를 확인하고 이제 초기화되었는지 확인합니다.
```
glengoyne> pktool tokens
Flags: L=Login required  I=Initialized  X=User PIN expired  S=SO PIN expired
Slot ID  Slot Name   Token Name                    Flags
-------  ---------   ----------                    -----
1        Sun Crypto  Softtoken         Sun Software PKCS#11 softtoken
2        Oracle Key Management System              KMS   LI
```
7. Solaris 시스템에서 cryptoadm(1M) 명령을 사용하여 지원되는 메커니즘을 표시하도록 요청하여 pkcs11_kms 토큰이 초기화되었는지 확인합니다.
```
glengoyne> cryptoadm list -m -p  provider=/usr/lib/security/'$ISA'/pkcs11_kms.so.1
Mechanisms:
CKM_AES_KEY_GEN
CKM_AES_CBC
CKM_AES_CBC_PAD
glengoyne>
```
  Solaris 시스템에서 pktool(1) 유틸리티를 사용하여 다음과 같이 pkcs11_kms 공급자를 통해 키를 만들고 나열합니다.
```
 # pktool genkey token=KMS keytype=aes keylen=256
   label=MyKey-test1
 # pktool list token=KMS objtype=key
 # pktool list token=KMS objtype=key label=MyKey-test1
```
  OKM Manager GUI 또는 OKM CLI를 통해 OKM 시스템의 키를 볼 수 있습니다.
주:
Solaris의 경우, kmscfg(1)는 기본적으로 사용자당 슬롯 구성을 한 번에 하나만 만듭니다.
추가 슬롯 구성을 정의할 수 있지만 프로세스당 하나만 활성화됩니다. 이렇게 하려면 KMSTOKEN_DIR 변수를 사용하여 대체 슬롯 구성 및 파일 시스템 위치를 정의하면 됩니다.

Solaris 11 기본값은 /var/user/$USERNAME/kms이지만 고유한 이름 지정 체계를 만들 수 있습니다. 이를 위한 최선의 방식은 다음과 같을 수 있습니다.

/var/user/$USERNAME/$AGENTID-$CLUSTER/

이 이름 지정 규칙으로 인해 Solaris는 다양한 사용 시나리오에 따라 여러 슬롯-에이전트-클러스터 조합을 가질 수 있습니다.

일부 PKCS#11 구성의 경우 대체 위치가 권장됩니다. 예를 들어, Oracle RAC에서 TDE를 사용하는 경우(위의 TDE 구성 섹션 참조), 각 노드가 pkcs11_kms 공급자의 메타 데이터를 공유할 수 있습니다.
자동 열기 전자 지갑을 사용하도록 TDE를 구성하려면 이 부록의 시작 부분에서 참조되는 Oracle Advanced Security Transparent Data Encryption Best Practices 문서에서 설명되는 지침을 따르십시오.

상시 작업

다음 섹션에서는 반복되는 OKM 및 TDE 작업에 대해 설명합니다.

Oracle Wallet에서 마스터 키 마이그레이션

이전 전자 지갑이 보존되어야 하며, 새 마스터 키는 OKM에서 생성되며 키 관리 시스템에 의해 안전하게 보호됩니다.

이 부록의 시작 부분에서 참조되는 Oracle Advanced Security Transparent Data Encryption Best Practices 문서를 참조하십시오.

TDE는 각 마스터 키를 식별하는 고유한 키 레이블을 생성합니다. 실제 키 값은 pkcs11_kms 토큰에서 TDE로 전달되기 전까지 일반 텍스트로 노출되지 않습니다. "생성된" 키는 활성 상태의 AES 256비트 키 풀에서 가져옵니다(안전하게 다중 KMA로 복제됨). 이 키는 그런 다음 PKCS#11 토큰에서 사용되는 특정 에이전트에 따라 OKM 키 정책과 연관됩니다. 그런 다음 OKM은 정책에 지정된 키 수명 주기에 따라 키를 관리합니다.

키 다시 입력 작업

Oracle 데이터베이스 관리자는 키의 수명 주기가 시작되기 전에 키 다시 입력 작업을 수행해야 합니다. 그렇지 않으면 데이터베이스가 시작되지 않습니다.

이 작업을 수행하는 데 사용되는 DDL에 대해서는 여러 가지 Oracle 데이터베이스 및 TDE 문서를 참조하십시오. 키 다시 입력은 Oracle Enterprise Manager를 사용하여 수행할 수도 있습니다.

OKM 정책 기반 키 만료로 인한 키 다시 입력

키가 사후 작업 상태에 도달한 후 TDE에서 키 검색을 수행할 때마다 OKM 감사 로그에 사후 작업 키가 검색되었음을 나타내는 경고가 트리거됩니다. 이러한 감사 메시지가 있으면 데이터베이스 인스턴스의 마스터 암호화 키를 다시 입력해야 함을 나타냅니다. OKM 감사 메시지는 특정 에이전트, Oracle 데이터베이스 인스턴스의 식별을 지원하기 위해 검색 중인 키, 그리고 사후 작업 상태에 도달한 마스터 암호화 키를 식별합니다. OKM에서 SNMP v3 정보 또는 SNMP v2 트랩을 통한 통지를 구성하여 이 프로세스를 자동화할 수 있습니다.

pkcs11_kms 공급자는 키가 사후 작업 상태에 도달했음을 PKCS#11 소비자에게 알리려고 시도합니다. 이 작업은 마스터 키에 대해 PKCS#11 "CKA_ENCRYPT" 속성을 false로 설정하여 수행됩니다.

Oracle Database 11gR2는 현재 키를 사용하여 암호화 기간이 만료된 후에도 데이터를 계속 암호화합니다. 이러한 동작은 다음 오류가 경보 로그에 표시되었을 때 확인할 수 있습니다.

HSM heartbeat died. Likely the connection has been lost. PKCS11 function C_EncryptInit returned
PKCS11 error code: 104
HSM connection lost, closing wallet

이 오류가 발생하면 데이터베이스 관리자가 다음 작업을 수행해야 합니다.

pkcs11_kms 토큰과 연관된 사용자에 대해 다음 환경 변수를 설정합니다(일반적으로 Oracle 사용자의 프로파일).
```
# export PKCS11_KMS_ALLOW_ENCRYPT_WITH_DEACTIVATED_KEYS=1
```
데이터베이스를 다시 시작합니다.
데이터베이스 인스턴스에 대한 마스터 키를 다시 입력합니다.

위에 설명된 오류를 방지하려면 Oracle 데이터베이스 에이전트와 연관된 OKM 키 정책에서 암호화 기간을 매우 길게 설정하는 것이 좋습니다. 또는 pkcs11_kms 공급자의 동작을 변경하여 키 상태 검사를 사용 안함으로 설정할 수 있습니다. 이렇게 하려면 위의 1단계에서 설명된 대로 환경 변수를 설정합니다. 이 변수가 설정된 다음에는 HSM을 열 수 있습니다.

이렇게 해도 TDE는 계속 키를 사용하고 자동 키 다시 입력 작업을 수행하지 않습니다. 사후 작업 키 검색 감사 경고가 발생한 경우 OKM 관리자는 데이터베이스 관리자에게 데이터베이스 인스턴스의 마스터 키를 다시 입력해야 한다고 알려야 합니다.

다른 HSM 솔루션에서 변환

다른 공급업체의 HSM 솔루션을 OKM으로 변환하는 데 필요한 특정 단계는 Oracle 기술 지원에 문의하십시오.

키 삭제

사후 작업 단계에 도달한 키를 삭제하기 전에 OKM 관리자는 해당 키가 더 이상 사용되고 있지 않은지 확인해야 합니다.

OKM 관리자는 사후 작업 단계에서 일반적인 키 삭제를 수행합니다. pkcs11_kms 공급자를 통한 키 삭제는 OKM에서 지원되지 않으며, 운영자 역할이 지정된 OKM 사용자를 위해 예약된 제한된 작업입니다. 키가 삭제된 다음에는 PKCS#11 C_FindObjects 요청을 비롯해 이를 검색하려는 모든 시도가 실패합니다.

Oracle RMAN 및/또는 Oracle Data Pump가 지원되는 키 전송

Oracle RMAN 및/또는 Oracle Data Pump를 사용하려면 재해 복구 사이트 또는 파트너에서 마스터 키를 다른 OKM 클러스터에 제공하는 기능이 필요할 수 있습니다. OKM 키 전송 작업은 보안 키 내보내기 및 키 가져오기 서비스를 사용하여 이를 즉시 지원합니다. 자세한 내용은 "키 전송"을 참조하십시오.

다음 단계를 수행하십시오.

소스 및 대상 OKM 클러스터 사이에 키 전송 파트너를 설정합니다.
Oracle RMAN 백업 지원을 위해 내보낼 TDE 마스터 키 또는 Oracle Data Pump를 사용하여 내보낸 암호화된 데이터를 식별합니다.
소스 OKM 클러스터에서 키를 내보냅니다. 그러면 소스 키 내보내기 파일이 생성됩니다.
내보낸 키 파일을 전송 파트너로 전송합니다.
대상 전송 파트너는 해당 OKM 클러스터로 키를 가져옵니다.

Oracle RMAN 복원 또는 Oracle Data Pump 가져오기를 실행하여 키가 필요한 데이터베이스 인스턴스를 다시 만듭니다. 이렇게 하려면 가져오기 위치에서 OKM에 TDE를 사용하는 데 필요한 구성 단계가 필요합니다. 그런 다음 복원 또는 가져오기 작업은 데이터베이스 인스턴스에서 사용되는 열 또는 테이블스페이스 키를 해독하는 데 필요한 범용 마스터 키를 위해 OKM에 액세스합니다.

관리

시스템이 활성 상태가 되면 다음 지침에 따라 솔루션을 효율적으로 관리 및 모니터합니다.

증명, 감사 및 모니터링

Oracle은 다음 사항을 권장합니다.

문제 확인을 위해 TDE 에이전트의 OKM 활성 내역을 검토하고 모니터합니다.
감사자는 OKM 감사 이벤트를 사용하여 TDE가 OKM 클러스터에서 마스터 키에 액세스하고 있음을 증명할 수 있습니다.
OKM에 대해 SNMP 관리자를 구성합니다.
OKM CLI 사용을 탐색하여 기업별 보고서를 생성합니다.

OKM에서 TDE 마스터 키 찾기

GUI 관리 도구 또는 CLI를 사용하여 OKM 내에서 TDE 마스터 키를 찾을 수 있습니다. TDE는 마스터 키 레이블을 생성하고, OKM은 데이터 장치의 외부 태그 속성을 사용하여 이 값을 저장합니다. TDE 마스터 키 생성(키 다시 입력 작업 포함)은 OKM 클러스터 내에서 항상 새로운 데이터 장치 객체 및 키 객체를 만듭니다.

TDE 마스터 키를 찾으려면 다음을 수행합니다.

OKM 데이터 장치에서 질의를 수행하고 "ORACLE.TDE"로 시작하는 "ExternalTag"와 같은 ExternalTag 필터를 사용하여 목록을 필터링합니다. 모든 TDE 키 레이블은 이 문자열로 시작하므로 TDE에서 생성된 OKM 데이터 장치 목록이 생성됩니다. 각 OKM 데이터 장치에는 이와 연관된 단일 TDE 마스터 키가 포함됩니다. OKM GUI로 이러한 키를 검토하여 해당 수명 주기 상태 및 기타 등록 정보(예: 키 그룹, 내보내기/가져오기 상태 및 삭제된 키가 포함된 OKM 백업)를 검사할 수 있습니다. OKM CLI를 사용하여 이러한 키를 확인할 수도 있습니다. 예를 들면 다음과 같습니다.
```
>okm listdu --kma=acme1 --user=joe \
--filter="ExternalTag=ORACLE.TDE"
```
여러 Oracle 데이터베이스 인스턴스가 OKM 클러스터를 공유할 경우, OKM 관리자는 데이터베이스 인스턴스에 해당하는 에이전트의 감사 이벤트에 대한 질의를 사용하여 특정 데이터베이스에 해당하는 키를 식별할 수 있습니다. 이러한 감사 이벤트는 Oracle GUI를 사용하여 확인할 수 있습니다. "CreateDataUnit과 동일한 작업"과 같은 필터를 사용하여 에이전트의 감사 내역을 필터링합니다. 그러면 TDE 마스터 키 만들기에 해당하는 감사 이벤트 목록이 생성됩니다. 감사 이벤트 세부 정보에는 마스터 키에 대해 특정 데이터 장치를 식별하는 데 필요한 정보가 제공됩니다. OKM CLI를 사용하여 이러한 감사 이벤트를 확인할 수도 있습니다. 예를 들면 다음과 같습니다.
```
>okm listauditevents --kma=acme1 --user=joe \
--filter="Operation=CreateDataUnit"
```

문제 해결

이 섹션에서는 OKM에서 TDE를 사용할 때 발생할 수 있는 오류 조건들에 대해 설명합니다.

마스터 키를 검색할 수 없음

마스터 키를 검색할 수 없으면 Oracle 데이터베이스에서 다음 오류 중 하나가 보고됩니다.

ORA-28362
ORA-06512

이러한 오류가 발생하면 다음 진단 단계를 수행하여 문제를 식별합니다.

$ORACLE_BASE/diag/rdbms/$SID/$SID/trace/alert_$SID.log 파일을 검사합니다. 이 파일에는 암호화 전자 지갑에 액세스하기 위해 사용된 "alter" DDL 문과 관련된 성공/실패 메시지가 기록됩니다.
pkcs11_kms 구성 디렉토리($KMSTOKEN_DIR/KMSAgentLog.log)에서 KMSAgentLog.log 파일을 검사합니다.
OKM의 일반 상태를 확인합니다. 다음 사항을 확인합니다.
- KMA가 활성 상태입니까?
- KMA가 잠겨 있습니까?
- 키 풀이 고갈되었습니까?
- KMA ILOM/ELOM 결함
- KMA 콘솔 메시지
앞에서 설명한 대로 pkcs11_kms 토큰의 상태를 확인합니다.
에이전트가 등록되고 사용으로 설정되었는지 확인하기 위해 에이전트에 대해 OKM 감사 이벤트를 검사하여 에이전트 상태를 확인합니다.
Oracle 데이터베이스 호스트에서 OKM 노드로의 네트워크 연결을 확인합니다.
Oracle 기술 지원에 문의합니다. 하나 이상의 KMA 시스템 덤프를 제공해야 할 수 있습니다.

pkcs11_kms 구성 디렉토리 손실

손실 또는 손상된 pkcs11_kms 토큰 프로파일을 복구하려면 다음 절차를 수행합니다.

"OKM의 TDE 구성"에 설명된 구성 단계를 수행합니다.
Solaris 전용 - OKM에서 "ORACLE.TDE"로 시작하는 "ExternalTag"와 같은 데이터 장치 필터를 사용하여 토큰의 메타 데이터를 다시 채웁니다.
Solaris 전용 - 이 목록의 결과를 파일(예: "du.lst")로 저장하고 다음 셸 스크립트를 실행합니다.
```
for label in `awk '{print $2}' < du.lst `
do
pktool list token=KMS objtype=key label="${label}"
done
```

슬롯을 사용할 수 없음 오류

PKCS#11 작업을 실행할 때 클라이언트에 "No Slots Available" 오류가 발생합니다.

kmscfg 유틸리티가 성공적으로 실행되었는지 확인합니다.
pkcs11_kms 공급자가 올바르게 설치 및 구성되었는지 확인합니다.

CKA_GENERAL_ERROR 오류

키를 검색하려고 할 때 클라이언트에서 CKA_GENERAL_ERROR 오류가 발생합니다.

에이전트의 OKM 클러스터에 기본 키 그룹이 있는지 확인합니다.
자세한 내용은 $KMSTOKEN_DIR/KMSAgentLog.log 파일을 참조하십시오.

PKCS#12 파일을 열 수 없음 오류

"Could not open PKCS#12 file" 오류가 $KMSTOKEN_DIR/KMSAgentLog.log 파일에 표시됩니다.

OKM 클러스터에서 감사 이벤트를 선택하여 에이전트 문장암호가 최근에 변경되었는지 확인합니다.
$KMSTOKEN_DIR에서 <profile-name> 디렉토리를 제거합니다.