키 저장소 우수 사례

키 저장소 및 마스터 키의 보안을 유지하기 위해 보안 우수 사례를 사용하십시오.

키 저장소 신임 정보

대부분의 키 저장소 구성에서 저장된 키에 대한 액세스가 허용되기 전에 신임 정보가 키 저장소에 전달되어야 합니다. 이후 Db2 는 키 저장소에 대한 액세스 권한이 있어야 합니다, Db2 는 키 저장소 자격 증명에 대한 액세스 권한도 있어야 합니다. 이 정보는 db2start 명령 실행 시 필요합니다. Db2 키스톤 신임 정보를 안전하게 제공하는 여러 가지 방법이 있습니다.
  • 운영자가 신임 정보를 입력할 수 있는 프롬프트
  • 제공된 파일 인수를 통한 액세스
  • “stash” 파일의 사용
stash 파일은 키 저장소에 액세스하는 데 필요한 신임 정보를 포함하는 난독화 파일입니다. 이 파일을 Db2 인스턴스 소유자만 읽을 수 있도록 설정하십시오. 스태쉬 파일을 작성하는 방법에 대한 세부사항은 자세한 키 저장소 구성 정보에 제공됩니다.
주: 스태쉬 파일을 사용하는 것 외에 비밀번호를 백업해야 합니다. 이는 특히 로컬 키 저장소 파일에 사용되는 암호에 적용됩니다. stash 파일이 손상되면 암호를 수동으로 제공해야 합니다. 암호를 잊어버리고 백업을 작성하지 않은 경우 키 및 데이터에 대한 액세스 권한이 유실됩니다.

로컬 키스톤 파일의 비밀번호를 작성하거나 변경하는 경우, gsk8capicmd_64 명령의 –strong 매개변수를 사용하여 비밀번호가 강력한지 확인하십시오. gsk8capicmd_64 명령의 전체 구문에 대한 자세한 정보는 GSKCapiCmd 사용자 안내서를 참조하십시오.

키 저장소 백업

키 저장소의 컨텐츠는 중요하므로 정기적인 간격으로 키 저장소를 백업하는 것이 중요합니다. 키 저장소의 컨텐츠가 변경될 때마다(예: 키 또는 인증서가 추가되는 경우, 마스터 키(MK)가 회전되는 경우 또는 암호가 변경되는 경우) 백업을 수행해야 합니다.
주: 암호 변경이 있을 때 백업은 모든 키 스토어가 아닌 스태쉬 파일에만 적용됩니다. 이는 로컬 키 저장소 파일에도 적용됩니다.

키 저장소 구성 파일은 Db2 데이터베이스 백업의 일부로 포함되지 않으며 수동으로 백업해야 합니다. 디스크에 저장된 키 저장소 신임 정보도 수동으로 백업해야 합니다.

로컬 키 저장소 파일의 경우, 구성 파일은 Db2 데이터베이스 백업의 일부로 포함되지 않으며 수동으로 백업해야 합니다.

중앙 집중식 키 저장소의 경우 키 저장소 백업에 대한 해당 권장사항을 이해하려면 키 저장소 제품에 대한 문서를 참조하십시오.

MK 레이블 고유성

Db2 는 MK 레이블을 사용하여 각 MK를 고유하게 식별하고 각 암호화된 오브젝트 (데이터베이스, 트랜잭션 로그 또는 백업 파일) 에 레이블 값을 저장합니다. 이 저장된 레이블 값은 데이터 암호화 키(DEK)를 복호화하는 데 사용되는 MK를 식별하며 오브젝트에서 데이터를 암호화하는 데 사용됩니다. 중복을 피하기 위해 고유한 MK 레이블을 사용하는 것이 중요합니다. 고유한 레이블을 사용하지 않는 경우 암호화된 데이터에 대한 액세스가 유실될 수 있습니다. 레이블에 대해 키 저장소에서 검색되는 MK가 오브젝트에서 DEK를 암호화하는 데 사용되는 MK와 다른 경우 암호화된 데이터에 대한 액세스가 유실됩니다.

마스터 키 보존

암호화된 데이터베이스, 트랜잭션 로그 및 백업 이미지에 저장된 DEK에 액세스하려면 MK가 필요합니다. 이러한 오브젝트의 수명 기간 동안 다중 MK가 존재할 수 있으므로 암호화된 데이터가 보유되는 동안에는 해당 MK를 보유해야 합니다. 따라서 키 저장소에서 MK를 삭제하지 마십시오.

키 저장소 구성 변경

Thoughtful 계획은 모든 변경사항이 온라인으로 완료될 수 없기 때문에 Db2 데이터베이스 관리 키 저장소 구성 매개변수 또는 키 저장소 구성의 컨텐츠에 대한 변경사항을 선행해야 합니다. 각 새 키 요청은 키 저장소에 액세스할 때 이러한 값을 읽습니다. 일부 예외가 있는 경우 이러한 구성 값에 대한 변경사항은 다음 키 요청에 대한 Db2 처리에 반영됩니다. Db2 데이터베이스 관리자 구성 매개변수 keystore_type 및 keystore_location 을 온라인으로 구성할 수 있지만 단일 db2 update dbm cfg 명령으로 설정해야 합니다. 그렇지 않으면, Db2 가 갱신 사이의 키 저장소에 액세스하고 액세스 오류를 보고하려고 시도할 수 있습니다.

SSL_KEYDB, SSL_KEYDB_STASH 및 SSL_KMIP_CLIENT_CERTIFICATE_LABEL 키 저장소 구성 값에 대한 변경을 적용하려면 인스턴스 재시작이 필요합니다. 라이브러리 키 저장소 구성 값에 대한 변경사항은 Db2 가 다시 시작될 때까지 적용되지 않습니다. 마찬가지로 구성 값이 변경되지 않으면 Db2 가 다시 시작될 때까지 라이브러리의 실제 사본에 대한 변경사항이 적용되지 않습니다. Db2 가 정기적으로 키 저장소에 액세스할 수 있으므로, 잠재적 오류를 방지하기 위해 구성을 변경할 때 Db2 를 중지하는 것이 좋습니다. 암호화된 데이터베이스와 암호화되지 않은 데이터베이스가 동일한 인스턴스 아래 섞여 있는 경우 암호화되는 해당 데이터베이스를 quiesce하는 것으로 충분합니다.

키 회전

키 회전은 암호화 키를 변경하는 프로세스를 의미하며 준수 목적으로 필요한 경우가 많습니다. 키 회전은 키가 존재하는 동안 키의 노출로 인해 발생할 수 있는 위험을 줄이기 위해 수행됩니다. 암호화를 위해 Db2 가 사용하는 DEK가 암호화된 데이터베이스, 백업 또는 트랜잭션 로그의 외부에 있지 않으므로 노출 위험이 거의 없습니다. 이는 데이터베이스 외부에 있는 MK에도 동일하게 적용됩니다. Db2 는 SYSPROC.ADMIN_ROTATE_MASTER_KEY 프로시저. 이 프로시저는 이전 MK를 사용하여 임베디드 DEK를 복호화한 다음 새 MK를 사용하여 이를 다시 암호화합니다. MK의 회전은 기존 백업 또는 아카이브된 트랜잭션 로그 내 DEK의 암호화에는 영향을 주지 않지만 향후 DEK 입력에는 영향을 미칩니다. HADR 환경의 1차 데이터베이스에서 키를 회전하면 대기 상태에서 키 회전을 자동으로 구동합니다. 그러나 다른 로그 레코드가 대기 데이터베이스에 전송될 때까지 변경은 발생하지 않습니다. 회전된 키가 대기 상태가 되도록 강제 실행하려는 경우 아카이브 로그 명령을 사용하여 대기 상태에서 회전을 재생하는 데 필요한 로그 레코드를 생성할 수 있습니다. MK가 회전되는 경우 데이터베이스는 새 키를 즉시 사용하기 시작하지만 다음과 같은 시나리오에서는 이전 MK 값에 대한 액세스가 계속 필요합니다.
  • 키 회전 이후 재사용되지 않은 트랜잭션 로그 파일
  • 이전 MK 값을 사용한 아카이브된 암호화된 트랜잭션 로그 파일
  • 이전 MK 값을 사용한 암호화된 백업 이미지
암호화된 모든 오브젝트가 MK를 더 이상 참조하지 않을 것임이 확실하지 않으면 키 저장소에서 MK를 삭제하지 마십시오.