®키 관리
HSM은 키가 올바르게 생성, 사용, 갱신, 백업될 때 비로소 귀사의 애플리케이션을 보호합니다. 저희는 애플리케이션과 키 서비스를 연동하고, 운영과 개발이 안정적으로 활용할 수 있도록 라이프사이클을 설계합니다.
귀사가 OTOKO®에 맡기는 업무
PKCS#11은 암호 토큰을 위한 인터페이스를 정의하며, KMIP와 같은 키 관리 프로토콜은 이와 다른 통합 방식을 다룹니다. 저희는 귀사의 애플리케이션이 무엇을 지원하는지, HSM 내에서 어떤 연산이 이루어져야 하는지를 검토합니다. 표준 이름만으로는 상호 대체 가능성이 보장되지 않습니다. 메커니즘, 객체 속성, 세션, 프로바이더 동작 방식은 실제 연동 환경에서 테스트합니다. 데이터 암호화의 경우 저희는 데이터 암호화와 키 암호화를 구분하여, 키 접근과 대량 데이터 처리가 합리적으로 분산되도록 합니다.
구체적인 범위, 귀사의 참여 방식, 검수 기준은 시작 전에 함께 정합니다.
이해하기 쉽게 정리한 기술
새로운 키가 생겼다고 해서 이전 키를 바로 삭제할 수 있는 것은 아닙니다. 저희는 어떤 데이터, 서명, 백업이 여전히 이전 버전에 의존하는지를 파악합니다. 애플리케이션에는 키 버전에 대한 명확한 매핑이 필요합니다. 생성, 활성화, 폐기, 보관, 삭제는 각각 분리된 상태와 승인을 가집니다. 세션 고갈, 만료된 로그인, 연결 중단과 같은 오류는 숨기지 않고 명확히 드러나도록 처리합니다. 재시도로 인해 의도하지 않은 키 중복이나 업무상 중복된 처리가 발생해서는 안 됩니다.
테스트에서는 성공적인 호출뿐 아니라 거부된 역할과 허용되지 않는 연산도 검증합니다. 자격 증명과 시크릿은 소스 코드, 로그, 일반 백업에 남아서는 안 됩니다. 귀사의 팀은 구성, 예시 시나리오, 진단 절차를 전달받습니다. 시작을 위해서는 사용 중인 라이브러리, 런타임 환경, 기존 키 현황이 중요합니다.
PKCS #11은 암호 토큰과 그 기능에 대한 접근 방식을 정의합니다. KMIP는 클라이언트와 키 관리 시스템 간 암호 객체 관리를 다룹니다. 한편 클라우드 서비스는 자체 REST API를 제공할 수 있습니다. 그렇다고 해서 이들을 자동으로 서로 대체할 수 있는 것은 아닙니다. OTOKO®는 어디에서 연산이 실행되는지, 인터페이스가 실제로 어떤 키 자료를 전달하는지, 어떤 속성이 유지되는지를 문서화합니다. 이를 통해 단순한 프로토콜 목록이 명확한 통합 경로로 바뀝니다.
계층적 암호화에서는 데이터 키가 실제 데이터를 보호하고, 상위 키가 이 데이터 키를 보호할 수 있습니다. 이를 통해 모든 대용량 데이터 블록을 HSM에서 처리해야 하는 상황을 피할 수 있습니다. 중요한 것은 데이터 키가 평문으로 어디에서 필요한지, 그리고 그곳에 얼마나 오래 남아 있는지입니다. 저희는 애플리케이션 내에서의 캐시 동작, 키 교체, 접근을 명확히 합니다. “키는 HSM 안에 남아 있습니다”라는 말은 구체적으로 검토된 해당 키 역할과 그 속성에 대해서만 성립합니다.
여러 서비스가 지금까지 각자의 키 파일을 사용해 왔습니다. OTOKO®는 먼저 키별로 소유자, 목적, 데이터 종속성을 정리합니다. 이어서 대표 서비스 하나를 대상으로 지원되는 통합을 시험하고, 애플리케이션별 권한을 정의합니다. 전환은 단계적으로 진행되며, 기존 데이터의 읽기와 신규 데이터의 쓰기를 통제된 방식으로 처리합니다. 기존 키는 보존, 백업, 복구가 고려된 이후에야 제거됩니다. 그 결과 사용 및 교체 절차까지 테스트를 마친 키 인벤토리가 문서로 정리됩니다.
검증 가능한 결과
인계 과정은 구현과 문서화를 함께 아우릅니다. 합의된 사례를 함께 점검하고 남은 과제를 기록합니다.
첫 단계를 시작하기 전에
적합한 프로바이더와 필요한 메커니즘이 지원되는 경우라면 대체로 가능합니다. 저희는 구체적인 버전과 오류 발생 시 애플리케이션의 동작 방식을 검토합니다.
허용된 용도가 더 이상 없고 보존 및 복구 요구 사항이 명확히 정리된 이후에만 삭제됩니다. 키 교체와 삭제는 서로 별개의 단계입니다.
아닙니다. 새 키는 우선 신규 처리 건에만 사용할 수 있습니다. 기존 데이터를 재암호화해야 하는지, 아니면 데이터 키를 다시 래핑해야 하는지는 사용된 방식과 보호 목표에 따라 달라집니다. 이전 데이터와 백업은 계속 읽을 수 있어야 합니다.
클라이언트와 서버는 필요한 버전, 프로필, 객체 유형, 오퍼레이션을 지원해야 합니다. 인증, 객체 속성, 장애 발생 시 동작은 실제 제품 조합으로 테스트합니다.
상위 키는 HSM 내에서 보호되는 반면, 데이터 키는 래핑된 형태로 저장되며 데이터 처리를 위해 애플리케이션에서 일시적으로 사용될 수 있습니다. 저희는 일괄적으로 답하는 대신 각 키 역할에 대한 경계를 문서화합니다.
저희는 각 애플리케이션에 고유한 아이덴티티와 엄격히 제한된 권한을 부여합니다. 키 용도, 환경, 책임 소재에 따라 승인 범위가 결정됩니다. 네거티브 테스트를 통해 다른 애플리케이션의 키나 허용되지 않은 작업이 실제로 거부되는지 확인합니다.
