4.8

View in English

4.8 암호학과 키 관리

개요와 동기

여러분이 만드는 거의 모든 시스템은 이미 암호학, 곧 수학적 기법으로 정보를 보호해 의도된 당사자만 읽거나 신뢰할 수 있게 하는 실천에 의존합니다. 웹 트래픽은 암호화된 채널을 타고, 비밀번호는 해시되고, 소프트웨어 업데이트는 서명되고, 고객 데이터는 디스크에 암호화되어 있습니다. 대부분의 엔지니어에게 좋은 소식은 이 중 어느 것도 발명하라는 요구를 받지 않는다는 점입니다. 어려운 부분은 수학이 아닙니다. 검증된 구성 요소를 올바르게 쓰는 것이고, 무엇보다 그 구성 요소가 의존하는 키를 관리하는 것입니다.

이 장은 암호학자가 아닌 엔지니어, 곧 우리 거의 모두를 위해 쓰였습니다. 건전한 선택을 하고, 각 도구가 무엇을 보장하는지 알고, 강한 알고리즘을 거짓된 위안으로 만드는 실수를 피할 만큼의 이해가 필요합니다. 4.3장(인프라와 클라우드 보안)은 암호화와 키 관리를 지나가며 언급하고, 여기서는 무엇을 어떻게 암호화하는지와 그것을 현실로 만드는 키 수명 주기를 어떻게 운영하는지를 더 깊이 다룹니다.

대기업에서 암호학은 수천 개의 서비스, 인증서, 키에 걸쳐 뻗어 있고, 만료된 인증서 하나나 잃어버린 키 하나가 핵심 시스템을 내리거나 데이터 저장소를 유출시킬 수 있습니다. 정부에서 암호학은 흔히 의무화되고, 검증되고, 감사되며, 어떤 키가 어떤 비밀을 보호하고 누가 보유할 수 있는지를 정확히 정하는 데이터 분류 규칙이 있습니다. 두 환경 모두에서 되풀이되는 실패는 같습니다. 좋은 알고리즘이 엉성한 키 관리로 무너지는 것입니다.

핵심 원칙

  • 자체 암호를 만들지 마십시오. 검증되고 널리 리뷰된 라이브러리와 표준 알고리즘을 쓰십시오. 새로운 방식은 전문가만 잡는 방식으로 실패합니다.
  • 알고리즘은 쉬운 부분이고 키는 어려운 부분입니다. 키의 수명 주기에 실제 실패 대부분이 있습니다.
  • 각 프리미티브가 보장하는 것을 아십시오. 기밀성, 무결성, 진정성은 서로 다른 도구가 필요한 다른 속성입니다.
  • 기본으로 전송 중과 저장 시 암호화하십시오. 보호를 선택이 아니라 표준으로 만드십시오.
  • 키 보관과 데이터 접근을 분리하십시오. 키를 관리하는 사람이 그것이 보호하는 데이터를 자동으로 읽을 수 있어서는 안 됩니다.
  • 변화에 대비하십시오. 알고리즘은 약해지고, 키는 유출되고, 표준은 진화합니다. 첫날부터 교체와 이전을 위해 만드십시오.
  • 중요한 곳에서는 검증된 구현을 선호하십시오. 규제 및 정부 업무에서는 인정된 검증을 받은 모듈을 고르십시오.

권장 사항

자체 암호를 만들지 않는다

이것이 황금률이며 먼저 말할 가치가 있습니다. 자체 암호화 알고리즘을 설계하거나, 자체 프로토콜을 발명하거나, 논문에서 프리미티브를 손으로 구현하지 마십시오. 동작하는 암호는 단순해 보이면서 전문가의 여러 해 리뷰를 견뎌야 드러나는 미묘한 실패 양상(타이밍 부채널, 패딩 오라클, 약한 무작위성)을 숨기고 있습니다. 플랫폼의 표준 암호 모듈이나 평판 좋은 라이브러리 같은 확립된 라이브러리를 쓰고, 가능한 가장 높은 추상화 수준에서 쓰십시오. 저수준 조각을 직접 조립하는 대신 인증된 암호화 모드와 안전한 선택을 기본으로 만드는 “쉬운” 인터페이스에 손을 뻗으십시오.

프리미티브를 필요한 보장에 맞춘다

서로 다른 도구는 서로 다른 보장을 제공하며, 그것을 혼동하는 것은 흔하고 위험한 실수입니다. 세 가지 주요 계열을 배우십시오.

  • 대칭 키 암호학은 하나의 공유된 비밀 키로 암호화와 복호화를 모두 합니다. 빠르고 기밀성을 보호하지만 양 당사자가 이미 키를 공유해야 합니다. AES가 표준 일꾼입니다.
  • 공개 키 암호학은 수학적으로 연결된 키 쌍을 씁니다. 누구나 가질 수 있는 공개 키와 비밀로 지니는 개인 키입니다. 키 배포를 해결하고, 진정성(누가 보냈는가)과 무결성(변경되지 않았는가)을 증명하는 디지털 서명을 가능하게 합니다.
  • 암호학적 해시 함수는 데이터의 고정 크기 지문을 만들며 무결성 검사를 제공합니다. 해싱은 단방향이며 암호화가 아닙니다. 비밀번호를 저장할 때는 단순한 빠른 해시가 아니라 느리고 솔트가 있는 비밀번호 해싱 함수를 쓰십시오(애플리케이션 보안의 4.2장 참조).

실용적 교훈은 이렇습니다. 암호화는 데이터를 숨기지만 누가 보냈는지 증명하지 않고, 해시는 변조를 탐지하지만 아무것도 숨기지 않습니다. 대부분의 실제 시스템은 둘을 결합하며, 그래서 이것들을 올바르게 번들하는 라이브러리에 기대야 합니다.

최신 TLS로 전송 중 암호화한다

시스템 사이를 이동하는 데이터를 보호하는 프로토콜인 전송 계층 보안(TLS)으로 모든 네트워크 홉을 보호하십시오. 현대적 TLS 버전을 요구하고, 구식 버전을 끄고, 강한 암호 스위트를 고르고, “동작하게 하려고” 검사를 끄는 대신 인증서를 제대로 검증하십시오. 제로 트러스트 자세는 내부 네트워크가 적대적이라고 가정하므로, 공개 엣지만이 아니라 내부 서비스 간 트래픽도 암호화하십시오. TLS가 어디서나 힘 안 들이는 기본이 되도록 인증서 발급과 갱신을 자동화하십시오.

봉투 암호화로 저장 시 암호화한다

저장된 데이터를 기본으로 암호화하십시오. 데이터베이스, 객체 스토리지, 백업, 로그입니다. 표준 패턴은 봉투 암호화로, 데이터 암호화 키(DEK)가 실제 데이터를 암호화하고, 키 관리 서비스가 쥔 키 암호화 키(KEK)가 DEK를 암호화합니다. 이로써 테라바이트의 데이터를 다시 암호화하지 않고 마스터 키를 교체할 수 있고, 강력한 루트 키를 강화된 경계 안에 둘 수 있습니다. 감싸진 DEK만 데이터 옆에 저장하고, 사용 시점에 가져와 풀어내십시오.

키 수명 주기를 의도적으로 운영한다

키의 수명 주기는 암호학에서 진정으로 어려운 부분이며 대부분의 침해와 장애가 비롯되는 곳입니다. 모든 단계를 의도적으로 관리하십시오.

  • 생성: 적절한 강도로 강한 무작위 원천에서 키를 만드십시오.
  • 배포: 코드, 설정 파일, 채팅에 노출하지 않고 필요한 시스템에 키를 전달하십시오.
  • 교체: 일정에 따라 키를 교체하고, 침해가 의심되면 빠르게 교체할 수 있어야 합니다.
  • 폐기(revocation): 침해된 키나 인증서를 빨리 무효화하고, 시스템이 폐기를 존중하도록 하십시오.
  • 파기: 옛 키 자료를 복구할 수 없도록 안전하게 퇴역시키십시오.

이를 중앙화하려고 키 관리 서비스(KMS)를 쓰고, 가장 높은 보증이 필요한 키에는 키가 평문으로 떠나지 않도록 키를 생성하고 지키는 변조 방지 장치인 하드웨어 보안 모듈(HSM)을 쓰십시오. 키 보관이 직무 분리를 시행하도록, 키를 관리할 수 있는 사람을 보호되는 데이터를 읽을 수 있는 사람과 분리하십시오. 이는 4.5장(프라이버시와 데이터 보호)의 데이터 분류와 보관 규칙에 직접 연결됩니다.

비밀 관리와 키 관리를 구별한다

둘은 겹치지만 같지 않습니다. 키 관리는 암호 키와 그 수명 주기를 다스리며, 보통 날것의 키가 떠나지 않도록 대신 암호 연산을 수행하는 KMS나 HSM 안에서 이루어집니다. 비밀 관리는 서비스가 평문으로 가져와 써야 하는 애플리케이션 자격 증명(데이터베이스 비밀번호, API 토큰, 인증서)을 다스리며, 보통 수명이 짧고 감사되는 접근을 가진 비밀 볼트에서 이루어집니다. 키에는 KMS를, 자격 증명에는 비밀 관리자를 쓰고, 어느 쪽도 소스 코드나 버전 관리에 체크인된 환경 파일에 붙여넣지 마십시오.

PKI와 인증서 수명 주기를 자동화한다

공개 키 기반 구조(PKI)는 공개 키를 신원에 묶는 인증 기관, 인증서, 신뢰 사슬의 체계입니다. 규모에서 지배적인 PKI 위험은 서비스를 내리는 뜻밖의 인증서 만료입니다. 모든 인증서의 목록을 유지하고, 만료를 모니터링하고, 아무도 기억할 필요가 없도록 발급과 갱신을 자동화하십시오. 자동으로 갱신되는 수명이 짧은 인증서가 손으로 돌보는 수명이 긴 인증서보다 안전합니다. 자동화가 사람이라는 단일 장애점을 없애기 때문입니다. 여기의 표준 프로토콜은 벤더 간 상호운용성을 지원합니다(상호운용성과 개방형 표준에 관한 3.8장).

암호 민첩성과 양자 내성 이전을 위해 만든다

알고리즘은 시간이 지나며 약해지고 표준은 움직입니다. 암호 민첩성은 고통스러운 재작성 없이 알고리즘과 키 크기를 바꿀 수 있도록 시스템을 설계한다는 뜻입니다. 암호를 작은 인터페이스 뒤에 추상화하고, 암호화된 데이터에 버전을 매겨 어떤 알고리즘이 만들었는지 알고, 무엇을 어디에 쓰는지 암호 목록을 유지하십시오. 이는 미래의 양자 컴퓨터에 저항하도록 설계된 새로운 알고리즘 계열인 양자 내성 암호 때문에 지금 중요합니다. 적대자는 오늘 암호화된 데이터를 수확해 나중에 복호화할 수 있으므로, 수명이 긴 비밀에는 이전 계획이 필요합니다. 당황할 필요는 없지만 목록을 알고, 플랫폼이 출하하는 대로 표준화된 양자 내성 알고리즘을 채택할 준비를 해야 합니다.

요구되는 곳에서는 검증된 구현을 선호한다

규제 및 정부 시스템에서 강한 알고리즘을 쓰는 것만으로는 충분하지 않습니다. 구현이 검증되어야 합니다. FIPS 140(연방 정보 처리 표준 140)은 암호 모듈을 검증하는 미국 표준이며, 많은 계약이 FIPS 검증 암호를 요구합니다. 정부 업무는 분류된 시스템을 위한 NSA의 상용 국가 안보 알고리즘(CNSA) 스위트 같은 국가 지침도 따를 수 있습니다. 만들기 전에 어느 체계가 적용되는지 확인하십시오. 검증된 모듈을 늦게 사후 보강하는 것은 비싸기 때문입니다. 이는 컴플라이언스 증거와 거버넌스(4.6장)로 이어집니다.

장단점

결정장점단점
제공자 관리 KMS쉽고, 통합되어 있으며, 운영 부담이 낮음제공자가 보관. 직접 통제가 적음
고객 관리 키 / HSM완전한 보관. 엄격한 의무를 충족운영 오버헤드. 키를 잃을 위험
자동화된 수명이 짧은 인증서뜻밖의 만료 없음. 빠른 폐기선행 자동화 투자 필요
수명이 긴 인증서단순하고 움직이는 부분이 적음사람이 관리하는 만료가 장애를 일으킴
봉투 암호화싼 키 교체. 마스터 키 보호이해할 움직이는 부분이 더 많음
선행 암호 민첩성싼 미래 이전지금 추가 추상화와 설계 노력
이른 양자 내성 채택수명이 긴 비밀을 지킴미성숙한 도구. 더 큰 키. 일부 위험

핵심 긴장은 통제 대 운영 부담입니다. HSM에 자체 키를 쥐면 최대의 보관을 주고 가장 엄격한 의무를 충족하지만, 전문성을 요구하고 새로운 파국적 위험을 만듭니다. 키를 잃으면 데이터를 복구 불가능하게 잃습니다. 제공자 관리 서비스는 그 부담을 없애지만 보관을 제공자에게 둡니다. 계층화로 해결하십시오. 대부분의 시스템에는 합리적 기본값을 가진 관리형 서비스를 쓰고, 추가 통제가 비용과 위험만큼 값을 하는 가장 분류 등급이 높은 데이터에 고객 관리 키와 HSM을 남겨 두십시오.

팀과 논의할 질문

  1. 키, 인증서, 의존하는 알고리즘의 완전한 목록이 있습니까? 볼 수 없는 것은 교체, 이전, 감사할 수 없으며, 대부분의 조직은 아무도 추적하지 않는 것보다 훨씬 많은 암호 자료가 서비스 전반에 흩어져 있음을 발견합니다. 목록은 이후 모든 결정의 전제 조건입니다. 인증서 만료 모니터링, 키 교체, FIPS 범위 정하기, 양자 내성 계획이 모두 그것에 달려 있습니다. 현재 인증서와 만료일 목록을 가져와 누가 각각을 소유하고 만료되면 무엇이 깨지는지 물으십시오. 큰 자산에서 정직한 답은 대개 단일 진실 원천이 없다는 것이며, 하나를 만드는 것이 지렛대 효과가 가장 큰 첫 단계입니다. 오늘 암호를 열거할 수 없다면 민첩성과 교체는 능력이 아니라 열망입니다.

  2. 침해된 키를 빠르게 교체하거나 폐기할 수 있으며, 연습해 본 적이 있습니까? 교체와 폐기는 압박 아래서만 중요한 키 수명 주기의 부분이며, 팀은 인시던트 중에 키가 열두 곳에 하드코딩되어 있거나 폐기가 실제로 전파되지 않음을 일상적으로 발견합니다. 키를 교체하고 인증서를 폐기하는 목표 시간을 정하고, 필요하기 전에 리허설하십시오. 마지막 자격 증명 노출의 이야기를 가져와 교체가 실제로 무엇을 요구했는지 따라가 보십시오. 기업과 정부 시스템에서 리허설되지 않은 교체는 장기 노출과 자초한 장애 사이의 선택을 뜻할 수 있습니다. 교체가 한 번도 테스트되지 않았다면 동작하지 않는다고 가정하십시오.

  3. 키 보관은 어디에 있으며, 직무 분리를 시행합니까? 키를 관리할 수 있는 사람과 그것이 보호하는 데이터를 읽을 수 있는 사람이 같아서는 안 됩니다. 그 권한을 합치면 저장 시 암호화의 목적이 조용히 무너지기 때문입니다. 이 선택은 제공자 관리 키, 고객 관리 키, HSM 중 무엇을 쓰는지도 이끌며, 각각 다른 통제와 다른 운영 위험이 있습니다. 현재 키 정책을 가져와 어떤 단일 신원이 키를 관리하면서 그 뒤의 평문에 접근할 수 있는지 확인하십시오. 흔한 조용한 간극입니다. 규제 및 분류된 데이터에서는 보관 규칙이 데이터 분류(4.5장)와 의무로 정해질 수 있습니다. 보관과 접근이 분리되어 있지 않다면, 암호화는 대시보드가 시사하는 것보다 덜 보호하고 있습니다.

  4. 봉투 암호화를 보호하는 마스터 키를 잃거나 파기했다면 어떻게 복구하겠습니까? 고객 관리 키와 HSM은 보관을 주지만 새로운 파국적 실패 양상을 안깁니다. 키 암호화 키를 잃으면 그것이 감싸는 모든 데이터 암호화 키가, 그리고 그 뒤의 데이터가 영구히 읽을 수 없게 됩니다. 이를 해결하려던 바로 그 보관 문제를 조용히 다시 만드는 지나치게 넓은 백업이라는 반대 위험과 저울질하십시오. 현재 키 백업과 에스크로 방식, 각 마스터 키의 영향 범위, 복원이 문서화만 된 것이 아니라 실제로 수행되었다는 증거를 가져오십시오. 기업과 정부 자산에서는 이를 데이터 분류 규칙에 연결하십시오. 가장 민감한 키는 흔히 무심한 사본을 금지하므로, 복구는 의도적으로 설계되고, 일정에 따라 테스트되고, 퇴역한 키 자료가 파기되었음을 입증하라는 모든 규제 요건과 조정되어야 합니다.

  5. 시스템이 양자 내성 이전에 얼마나 준비되어 있으며, 수명이 긴 비밀 중 어느 것을 먼저 이전하겠습니까? 적대자는 오늘 암호화된 트래픽과 보관소를 수확해 양자 컴퓨터가 성숙하면 복호화할 수 있으므로, 몇 년간 기밀로 남아야 하는 모든 비밀은 이미 볼 수 없는 미래에 노출되어 있습니다. 경쟁하는 압력은 양자 내성 도구가 아직 어리고, 키가 더 크며, 너무 일찍 움직이면 안정되기 전에 바뀌는 알고리즘에 거는 위험이 있다는 점입니다. 암호 목록, 기밀로 남아야 하는 기간으로 순위를 매긴 비밀 목록, 아키텍처가 재작성 없이 알고리즘을 바꿀 수 있는지에 대한 정직한 판단을 가져오십시오. 정부와 규제 업무에서 수십 년의 기밀성 의무가 있는 기록은 이를 이론이 아닌 구체로 만들며, 조달은 곧 문서화된 이전 계획과 표준화된 양자 내성 알고리즘 지원을 요구할 수 있습니다.

  6. 규제가 검증된 암호를 요구할 때, 정확히 어떤 모듈이 범위에 있으며 자격이 되는지 압니까? 강한 알고리즘을 쓰는 것은 검증된 구현을 쓰는 것과 같지 않으며, 팀은 라이브러리, 언어 런타임, 클라우드 서비스가 계약이 요구하는 FIPS 140 경계에 덮이지 않음을 늦게 발견하는 경우가 흔합니다. 긴장은 검증된 모듈이 기능과 속도에서 최신 라이브러리에 뒤처질 수 있어, 그것을 고르는 것이 엔지니어링에 중요한 방식으로 스택을 제약한다는 점입니다. 각 규제 시스템이 실제로 호출하는 암호 모듈 목록, 그것을 덮는 검증 인증서, 적용되는 구체적 의무(FIPS 140, CNSA, 또는 분야 규칙)를 가져오십시오. 기업과 정부 프로그램에서는 만들기 전에 이를 결정하십시오. 검증된 모듈을 사후 보강하고 시스템을 사후에 재인가하는 것은 비싸고, 느리고, 완성했다고 생각한 바로 그 구성 요소의 재설계를 강제하는 경우가 많기 때문입니다.

분야별 관점

스타트업. 플랫폼의 검증된 기본값에 전적으로 기대고 맞춤 암호에 엔지니어링 시간을 0으로 쓰십시오. 관리형 저장 시 암호화를 켜고, 자동 갱신 인증서로 TLS를 종단하고, 표준 느린 함수로 비밀번호를 해시하고, 비밀을 저장소가 아닌 플랫폼의 비밀 관리자에 두십시오. 유일한 설계 결정은 애플리케이션에서 암호화하는 소수의 필드를 감싼 얇은 인터페이스이며, 그래야 나중에 제공자 관리 키에서 벗어나는 것이 재작성이 아닙니다.

소기업. 암호학자도 HSM을 운영할 의욕도 없으니 보관을 만들지 말고 사십시오. 클라우드나 SaaS 도구에 딸려 오는 제공자 관리 KMS와 비밀 관리자를 쓰십시오. 일을 위생으로 구성하십시오. 코드에 키 없음, 기본으로 어디서나 켜진 암호화, 아무것도 뜻밖에 실효되지 않도록 모니터링되는 인증서 만료입니다. 고객 관리 키는 계약이나 규제 기관이 정말 요구하는 드문 데이터에 남겨 두십시오.

대기업. 문제는 수천 개의 서비스, 인증서, 키에 걸친 규모와 일관성입니다. 봉투 암호화를 갖춘 중앙화된 KMS를 운영하고, 어떤 만료도 손으로 돌보지 않도록 전체 인증서 수명 주기를 자동화하고, 교체, FIPS 범위 정하기, 양자 내성 계획에 공급되는 단일 암호 목록을 유지하십시오. 키 보관과 데이터 접근의 분리를 조직 전체의 통제로 시행하고, 암호화를 각 팀이 다시 발명하는 작업이 아니라 모든 팀이 상속하는 플랫폼 능력으로 만드십시오.

정부. 조달, 검증, 감사가 모든 선택을 형성합니다. FIPS 140 검증 모듈만 쓰고 분류된 시스템에는 CNSA 같은 국가 지침을 따르고, 키 보관을 데이터 분류에 묶어 가장 민감한 키가 엄격한 직무 분리 아래 인가된 인원에게 있게 하고, 진행 중인 인가를 위해 검증된 암호의 지속적 증거를 생성하십시오. 수십 년 기밀로 남아야 하는 기록을 위해 문서화된 양자 내성 이전 계획을 두고, 확정하기 전에 벤더에게 어느 모듈이 검증되었는지 공개하도록 요구하십시오.

사례

스타트업. 건강 추적 앱을 만드는 작은 팀은 검증된 기본값에 전적으로 기댑니다. 자동 갱신 인증서로 TLS를 종단하고, 관리형 데이터베이스와 객체 스토리지에 제공자의 KMS로 저장 시 암호화를 켜고, 표준 라이브러리의 느리고 솔트가 있는 함수로 비밀번호를 해시합니다. 암호를 직접 쓰는 대신 애플리케이션에서 암호화해야 하는 한 필드에 고수준의 인증된 암호화 호출을 씁니다. 비밀은 저장소가 아닌 플랫폼의 비밀 관리자에 있습니다. 며칠의 오후가 들고 파국적 실수의 한 범주 전체를 없앱니다.

대기업. 한 글로벌 은행이 중앙화된 KMS와 HSM 군, 수천 개 서비스에 걸친 모든 키와 인증서를 추적하는 암호 목록을 운영합니다. 봉투 암호화가 고객 데이터를 보호하며, 데이터 키가 일정에 따라 교체되는 마스터 키로 감싸지는 동안 데이터는 그대로 있습니다. 인증서 발급과 갱신은 만료된 인증서 하나의 비용을 가르친 대외 장애 뒤에 완전히 자동화됩니다. 키 관리자는 애플리케이션 엔지니어와 별도 팀이어서 보관이 직무 분리를 시행하고, 암호 민첩성 계층 덕에 수명이 긴 보관소를 위한 양자 내성 알고리즘 시범을 시작할 수 있습니다.

정부. 분류된 기록을 다루는 한 국가 기관이 FIPS 140 검증 암호 모듈만 쓰고 가장 높은 분류 등급의 시스템에는 NSA CNSA 지침을 따릅니다. 키는 평문 키 자료를 결코 내놓지 않는 HSM에서 생성되고 보관되며, 보관은 데이터 분류에 묶여 가장 민감한 키가 엄격한 직무 분리 아래 인가된 인원에게 있습니다. 인증서는 자동화된 수명 주기를 갖춘 관리형 내부 PKI에서 돌고, 검증된 암호의 지속적 증거가 기관의 진행 중인 인가에 공급됩니다. 문서화된 양자 내성 이전 계획이 수십 년 기밀로 남아야 하는 기록을 보호합니다.

비즈니스 사례: 동기, ROI, TCO

암호학은 소소한 투자가 파국적이고 헤드라인급 손실을 막는 또 하나의 영역입니다. 총소유비용에는 KMS나 HSM, 비밀과 인증서 관리 도구, 수명 주기를 설계하고 목록을 최신으로 유지하는 엔지니어링 시간이 포함됩니다. 이 비용은 실재하지만 한정되어 있습니다. 건너뛰는 비용은 암호화되지 않은 데이터의 침해, 만료된 인증서로 인한 몇 시간의 장애, 잘못 다룬 키로 인한 복구 불가능한 데이터 손실이며, 각각 규제 벌금, 통지 비용, 지속적인 평판 손상을 동반합니다.

가장 강한 ROI는 자동화와 재사용에서 옵니다. 자동화된 인증서 수명 주기는 가장 흔한 자초한 장애를 없앱니다. 합리적 기본값을 가진 중앙화된 키 관리는 모든 새 서비스가 팀별 노력 없이 전송 중과 저장 시 암호화를 상속하게 해, 암호학을 반복되는 세금에서 플랫폼 능력으로 바꿉니다. 규제 및 정부 업무에서 검증된 모듈과 자동화된 증거는 감사와 인가의 비용도 낮춥니다. 리더십을 설득할 때 평이하게 구성하십시오. 알고리즘은 공짜이고 검증되어 있으며, 위험은 키 관리와 인증서 운영에 있고, 거기에 작고 자동화된 투자를 하면 비싼 실패를 막습니다.

안티패턴과 함정

  • 자체 암호 만들기. 미묘하고 전문가만 알아채는 방식으로 실패하는 맞춤 알고리즘이나 손으로 만든 프로토콜.
  • 하드코딩된 키와 비밀. 소스 코드, 설정 파일, 채팅에 붙여넣은 자격 증명으로, 유출되고 교체할 수 없는 것.
  • 키 규율 없는 암호화. 암호화는 켜지만 키 접근을 활짝 열어 두거나 교체하지 않는 것.
  • 해싱과 암호화의 혼동. 해시를 되돌릴 수 있는 것으로 다루거나, 느리고 솔트가 있는 것 대신 빠른 해시로 비밀번호를 저장하는 것.
  • 인증서 룰렛. 목록도, 만료 모니터링도 없이 인증서가 실효될 때 주기적으로 뜻밖의 장애가 나는 것.
  • 합쳐진 키 보관과 데이터 접근. 키를 관리하면서 그것이 보호하는 데이터도 읽을 수 있는 하나의 신원.
  • 교체 계획 없음. 한 번도 교체된 적 없고 압박 아래서 빨리 교체할 수 없는 키.
  • 민첩성 없는 암호. 알고리즘이 너무 깊이 배선되어 바꾸려면 재작성이 필요해, 미래의 어떤 이전도 막는 것.
  • 검증 의무 무시. FIPS 같은 검증이 요구되는 곳에서 검증되지 않은 모듈에 강한 알고리즘을 쓰는 것.

성숙도 모델

  • 1단계, 시작: 암호화가 일관되지 않고 흔히 없으며, 누군가 간극을 알아챌 때 반응적으로 적용됩니다. 키와 비밀이 하드코딩되거나 채팅과 설정 파일로 비공식적으로 공유됩니다. 목록도 교체도 없고, 인증서가 뜻밖에 만료되며, 팀이 가끔 자체 암호를 씁니다.
  • 2단계, 발전: 주요 시스템에 TLS와 저장 시 암호화가 켜져 있고 KMS나 비밀 관리자가 있지만, 채택은 고르지 않고 팀마다 다릅니다. 일부 인증서는 모니터링되고 다른 것은 아니며, 교체는 수동이고 드물고, 그것을 묶는 완전한 암호 목록이 없습니다.
  • 3단계, 표준화: 전송 중과 저장 시 암호화가 조직 전체에서 시행되는 문서화된 기본입니다. 키는 예정된 교체와 봉투 암호화를 갖춘 KMS에 있고, 키 보관이 데이터 접근과 분리되며, 인증서 수명 주기가 자동화되고, 암호 목록이 유지되며, 규제가 요구하는 곳마다 검증된 모듈이 쓰입니다.
  • 4단계, 관리: 암호 자산이 기준선에 대해 측정되고 통제됩니다. 인증서 만료 리드 타임, 일정대로 교체된 키의 비율, 침해된 키를 폐기하는 평균 시간, 기간당 코드 내 비밀 탐지, 목록 커버리지를 추적하고 목표에 대해 검토합니다. 교체와 폐기는 기록된 시간과 함께 주기적으로 리허설되고, 편차는 눈치채지 못한 채 지나가는 대신 시정 조치를 촉발합니다.
  • 5단계, 오케스트레이션: 암호학이 모든 서비스가 기본으로 상속하는 플랫폼 능력이며 조직 전체에서 지속적으로 개선되고 통합됩니다. 교체와 폐기가 빠르고 일상적으로 실행되며, HSM이 가장 높은 보증이 필요한 키를 보호하고, 암호 민첩성과 활발한 양자 내성 이전 계획이 알고리즘과 의무가 이동함에 따라 자산을 적응적으로 유지합니다. 컴플라이언스 증거가 자동으로 생성되어 진행 중인 인가에 공급됩니다.

논의를 위한 아이디어

  1. 자산의 어떤 시스템이 운영 비용과 파국적 손실 위험을 감안하고도 고객 관리 키나 HSM을 정당화합니까?
  2. 소유한 모든 키와 인증서의 단일 진실 원천을 어떻게 구축하고 유지하겠습니까?
  3. 오늘 침해된 키를 교체하는 현실적 시간은 얼마이며, 무엇이 그것을 느리게 합니까?
  4. 아키텍처의 어디에서 암호 알고리즘을 바꾸기 어려우며, 강제된 이전 전에 그것을 어떻게 고치겠습니까?
  5. 적대자가 지금 수확해 몇 년 뒤 복호화한다면 문제가 될 수명이 긴 비밀은 어느 것입니까?
  6. 비밀과 키가 코드, 설정, 로그에 들어가는 일이 있으며, 어떻게 알겠습니까?

핵심 요점

  • 자체 암호를 만들지 마십시오. 검증된 라이브러리와 표준 알고리즘을 안전한 가장 높은 추상화 수준에서 쓰십시오.
  • 알고리즘은 쉽고 키 관리는 어렵습니다. 키의 수명 주기(생성, 배포, 교체, 폐기, 파기)에 실제 실패가 있습니다.
  • 보장을 아십시오: 대칭 및 공개 키 암호화는 기밀성을 보호하고, 서명은 진정성과 무결성을 증명하며, 해싱은 변조를 탐지하지만 암호화가 아닙니다.
  • 최신 TLS로 전송 중, 봉투 암호화로 저장 시 암호화하는 것을 모든 시스템의 기본으로 하십시오.
  • 키 보관과 데이터 접근을 분리하고, 키에는 KMS를 자격 증명에는 비밀 관리자를 쓰고, 어느 쪽도 하드코딩하지 마십시오.
  • 인증서 수명 주기를 자동화해 뜻밖의 만료 장애를 없애고, 암호 목록을 유지하십시오.
  • 암호 민첩성을 위해 만들고 수명이 긴 비밀을 위한 양자 내성 이전 계획을 시작하십시오.
  • 규제나 분류가 요구하는 곳에서는 검증된 구현(FIPS 140과 해당 국가 지침)을 선호하십시오.

참고 문헌과 더 읽을거리

  • National Institute of Standards and Technology, FIPS 140-3: Security Requirements for Cryptographic Modules.
  • National Institute of Standards and Technology, SP 800-57: Recommendation for Key Management.
  • National Institute of Standards and Technology, SP 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths.
  • National Institute of Standards and Technology, post-quantum cryptography standards (FIPS 203, 204, and 205).
  • Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno, Cryptography Engineering.
  • Jean-Philippe Aumasson, Serious Cryptography.
  • David Wong, Real-World Cryptography.
  • Internet Engineering Task Force, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.
  • Open Web Application Security Project, Cryptographic Storage Cheat Sheet and Transport Layer Protection Cheat Sheet.
  • National Security Agency, Commercial National Security Algorithm (CNSA) Suite guidance.