이 절에서는 제품에서 제공하는 구체적인 보안 메커니즘의 개요를 살펴봅니다.
암호화 기반 에이전트를 사용하는 고객의 주된 문제는 다음과 같습니다.
정책 위반 시 정보 공개
데이터 손실 또는 삭제
비즈니스 연속성 사이트 등에서의 심각한 오류 발생 시 허용할 수 없는 데이터 복원 지연
감지되지 않은 데이터 수정.
Oracle Key Manager 보안 기능의 목표는 다음과 같습니다.
암호화된 데이터가 공개되지 않도록 보호.
공격에 대한 노출 최소화.
뛰어난 안정성 및 가용성 제공.
보안 설명서의 이 절에서는 시스템이 대응해야 할 위협에 대해 대략적인 개요를 설명하며 각 보안 기능을 결합하여 공격에 대비하는 방법을 제공합니다.
이러한 보호를 제공하는 중요 보안 기능은 다음과 같습니다.
인증 – 권한이 부여된 개인만 시스템 및 데이터에 액세스할 수 있도록 합니다.
권한 부여 – 시스템 권한 및 데이터에 대한 액세스 제어로, 개인이 적절한 액세스 권한을 얻도록 하는 인증에 기초합니다.
감사 – 관리자가 인증 메커니즘 침해 시도와 액세스 제어 침해 시도나 성공을 감지할 수 있습니다.
Oracle Key Manager의 보안 및 인증 요소에 대한 자세한 내용은 다음 링크의 Oracle Key Manager Version 2.x Security and Authentication White Paper를 참조하십시오.
Oracle Key Manager 구조는 사용자 작업을 위해 시스템의 모든 요소 간(KMA와 KMA, 에이전트와 KMA, Oracle Key Manager GUI 또는 CLI와 KMA 간)에 상호 인증을 제공합니다.
시스템의 각 요소(예: 새 암호화 에이전트)는 OKM에서 ID 및 문장암호를 만들어 시스템에 등록됩니다. 해당 ID 및 문장암호는 추가될 요소에 입력됩니다. 예를 들어, 시스템에 테이프 드라이브가 추가되는 경우 에이전트와 KMA는 공유 문장암호를 기반으로 시도/응답 프로토콜을 자동 실행합니다. 이를 통해 에이전트는 에이전트에 대한 루트 CA(인증 기관) 인증서, 새 키 쌍 및 서명된 인증서를 얻습니다. 현재 위치에서 루트 CA 인증서, 에이전트 인증서 및 키 쌍을 사용하여 에이전트는 KMA와의 모든 후속 통신을 위해 TLS(Transport Layer Security) 프로토콜을 실행할 수 있습니다. 모든 인증서는 X.509 인증서입니다.
OKM은 루트 인증 기관으로 작동하여 루트 인증서를 생성하고, KMA는 이 루트 인증서를 사용하여 에이전트, 사용자 및 새 KMA에 사용되는 인증서를 파생(자체 서명)합니다.
액세스 제어 유형은 다음과 같습니다.
사용자 및 역할 기반 액세스 제어
쿼럼 보호
Oracle Key Manager는 각각 사용자 ID와 문장암호를 가진 여러 사용자를 정의할 수 있는 기능을 제공합니다. 각 사용자에게는 하나 이상의 미리 정의된 역할이 지정됩니다. 이러한 역할에 따라 사용자가 Oracle Key Manager 시스템에서 수행할 수 있는 작업이 결정됩니다. 역할은 다음과 같습니다.
보안 관리자 – Oracle Key Manager 설정 및 관리를 수행합니다.
운영자 – 에이전트 설정 및 일상적인 작업을 수행합니다.
준수 관리자 – 키 그룹을 정의하고 키 그룹에 대한 에이전트 액세스를 제어합니다.
백업 운영자 – 백업 작업을 수행합니다.
감사자 – 시스템 감사 추적을 확인합니다.
쿼럼 구성원 – 보류 중인 쿼럼 작업을 확인 및 승인합니다.
보안 관리자는 OKM 클러스터에서 KMA를 설정하는 QuickStart 프로세스를 수행할 때 정의됩니다. 나중에 추가 사용자를 정의하려면 사용자가 Oracle Key Manager GUI를 사용하여 보안 관리자로 클러스터에 로그인해야 합니다. 보안 관리자는 특정 사용자에게 여러 역할을 지정하도록 선택할 수도 있고, 여러 명의 사용자에게 하나의 특정 역할을 지정하도록 선택할 수도 있습니다.
각 역할에서 허용되는 작업 및 보안 관리자가 사용자를 만들고 해당 사용자에게 역할을 지정하는 방법에 대한 자세한 내용은 다음 링크의 Oracle Key Manager 설명서 라이브러리에 포함된 Oracle Key Manager 관리 설명서를 참조하십시오.
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
이 역할 기반 액세스 제어는 운영 기능을 구분할 수 있도록 NIST(National Institute of Standards and Technology) SP(Special Publication) 800-60 운영 역할을 지원합니다.
경우에 따라 중요한 작업을 수행하기 위해 추가적인 보안 레벨이 필요할 수 있습니다. OKM 클러스터에 KMA를 추가하고, KMA의 잠금을 해제하고, 사용자를 만들고, 사용자에게 역할을 추가하는 작업이 이에 해당합니다. 이러한 보안을 구현하기 위해 시스템에서는 앞서 설명된 역할 기반 액세스와 함께 일련의 키 분할 자격 증명을 사용합니다.
키 분할 자격 증명은 특정 작업을 완료할 수 있도록 시스템에 필요한 최소 개수의 쌍과 함께 일련의 사용자 ID와 문장암호 쌍으로 구성됩니다. 키 분할 자격 증명을 "쿼럼", 최소 개수를 "쿼럼 임계값"이라고도 합니다.
Oracle Key Manager에서는 최대 10개의 키 분할 사용자 ID/문장암호 쌍과 임계값을 정의할 수 있습니다. 이는 QuickStart 프로세스 중 OKM 클러스터에서 첫번째 KMA가 구성될 때 정의됩니다. 키 분할 사용자 ID 및 문장암호는 시스템에 로그인할 때 사용되는 사용자 ID 및 문장암호와 다릅니다. 사용자가 쿼럼 승인이 필요한 작업을 시도하면 정의된 키 분할 사용자 및 문장암호 임계값을 통해 이 작업이 승인되어야만 시스템에서 이 작업이 수행됩니다.
각 KMA는 OKM 클러스터에서 에이전트, 사용자 및 피어 KMA가 실행한 작업을 비롯하여 직접 수행하는 작업에 대한 감사 이벤트를 기록합니다. 또한 KMA는 에이전트, 사용자 또는 피어 KMA가 인증을 실패할 때마다 감사 이벤트를 기록합니다. 보안 위반을 나타내는 감사 이벤트에 유의해야 합니다. 보안 위반을 나타내는 감사 이벤트로는 인증 실패가 있습니다. OKM 클러스터에서 SNMP 에이전트가 식별되면 KMA는 보안 위반이 발생하는 경우 해당 SNMP 에이전트로 SNMP INFORM을 전송합니다. 원격 Syslog가 구성된 경우 KMA는 또한 이러한 감사 메시지를 구성된 서버로 전달합니다. 원격 Syslog를 참조하십시오.
사용자는 OKM 클러스터에 올바른 방식으로 로그인해야 하며 역할을 지정 받아야만 감사 이벤트를 확인할 수 있습니다.
KMA는 감사 이벤트를 관리하며, 보존 기간 및 제한(개수)을 기반으로 오래된 감사 이벤트를 제거합니다. 보안 관리자는 필요에 따라 이러한 보존 기간 및 제한을 수정할 수 있습니다.
Oracle Key Manager는 기타 보안 기능도 제공합니다. 기타 OKM 기능에 대한 자세한 내용은 다음 링크의 Oracle Key Manager Overview를 참조하십시오.
에이전트와 KMA, 사용자와 KMA, KMA와 피어 KMA 간의 통신 프로토콜은 동일합니다. 각각의 경우에 시스템에서는 통신을 시작하는 엔티티에 문장암호를 사용하여 시도/응답 프로토콜을 수행합니다. 성공하면 엔티티에 인증서 및 해당하는 개인 키가 제공됩니다. 이 인증서와 개인 키는 TLS(Transport Layer Security)(보안 소켓) 채널을 설정할 수 있습니다. 연결의 양쪽 끝이 서로 인증하는 상호 인증이 수행됩니다. OKM 3.1+ KMA는 피어 투 피어 복제 트래픽에 항상 TLS 1.2를 사용합니다.
KMA에서는 하드웨어 보안 모듈(별도로 주문 가능)을 사용할 수 있습니다. 이 하드웨어 보안 모듈, 즉 SCA(Sun Cryptographic Accelerator) 6000 카드는 FIPS 140-2 레벨 3 인증을 받았으며 AES(Advanced Encryption Standard) 256비트 암호화 키를 제공합니다. (이 인증서는 2015년 12월 31일에 만료된 후 갱신되지 않아 이후 릴리스에서는 대체 HSM이 제공될 예정입니다.) SCA 6000 카드는 FIPS 140-2 레벨 3 작동 모드를 지원하며 OKM은 항상 이 방식으로 카드를 사용합니다. OKM 클러스터가 FIPS 준수 모드로 작동하면 암호화 키가 SCA 6000 카드의 암호화 경계를 언래핑 형식으로 유지하지 않습니다. SCA 6000 카드는 SHA-1을 사용하여 암호화 키를 생성하는 FIPS 186-2 DSA 난수 생성기에 지정된 대로 FIPS에서 승인한 난수 생성기를 사용합니다.
KMA가 SCA 6000 카드를 사용하도록 구성되지 않은 경우 SCF(Solaris Cryptographic Framework) PKCS#11 소프트 토큰을 사용하여 암호화가 수행됩니다. SCF는 최근에 게시된 Solaris FIPS 140-2 보안 정책에 따라 FIPS 140 모드로 구성됩니다.
Oracle Key Manager는 키를 암호화하는 256비트 키와 함께 AES 키 래핑(RFC 3994)을 사용하여 만들어진 후 KMA에 저장되고 에이전트로 전송되거나 키 전송 파일 내에서 전송되는 대칭 키를 보호합니다.
OKM 클러스터의 첫번째 KMA가 초기화되면 KMA는 대용량 키 풀을 생성합니다. 클러스터에 KMA가 더 추가되면 새 KMA에 키가 복제되고 데이터 암호화에 사용되도록 준비됩니다. 클러스터에 추가된 각 KMA는 키 풀을 생성하여 클러스터의 피어 KMA에 복제합니다. 모든 KMA는 에이전트에 대해 항상 준비 키를 사용할 수 있도록 키 풀 크기를 관리하기 위해 필요에 따라 새 키를 생성합니다. 새 키가 필요할 경우 에이전트는 클러스터의 KMA에 연락하여 새 키를 요청합니다. KMA는 키 풀에서 준비 키를 인출하여 에이전트의 기본 키 그룹과 데이터 단위에 이 키를 지정합니다. 그런 다음 KMA는 네트워크를 통해 클러스터의 다른 KMA에 해당 데이터베이스 업데이트를 복제합니다. 나중에 에이전트는 클러스터의 다른 KMA에 연락하여 키를 검색할 수 있습니다. 일반 텍스트의 키 자료는 네트워크를 통해 전송되지 않습니다.
2013년 12월, NIST(National Institute of Standards and Technology)에서는 Solaris 11의 Oracle Solaris 커널 암호화 프레임워크 모듈에 대해 FIPS 140-2 레벨 1 검증 인증서 #2061을 수여했습니다. 2014년 1월, NIST에서는 Oracle Solaris Userland 암호화 프레임워크(SPARC T4 및 SPARC T5 사용)에 대해 FIPS 140-2 레벨 1 검증 인증서 #2076을 수여했습니다. Oracle Key Manager 3.1.0 KMA는 FIPS 140-2 검증 테스트가 아직 진행 중인 Solaris 11.3을 기반으로 합니다. Oracle Key Manager 3.1.0 KMA의 Oracle Solaris 커널 암호화 프레임워크는 Oracle 커널 암호화 프레임워크 보안 정책에 따라 구성되었습니다. 마찬가지로, KMA도 Oracle Solaris Userland 암호화 프레임워크(SPARC T4 및 SPARC T5 사용) 보안 정책에 따라 구성되었습니다. OKM은 출시될 때 최신 Solaris 보안 정책으로 업데이트될 예정입니다.