17장. NBDE(Network-Bound Disk Encryption)
17.1. 디스크 암호화 기술 정보
NBDE(Network-Bound Disk Encryption)를 사용하면 시스템을 다시 시작할 때 암호를 수동으로 입력하지 않고도 실제 및 가상 시스템에서 하드 드라이브의 root 볼륨을 암호화할 수 있습니다.
17.1.1. 디스크 암호화 기술 비교
에지 서버에서 유휴 상태의 데이터를 보호하기 위한 NBDE(Network-Bound Disk Encryption)의 장점을 이해하려면 Clevis 없이 키 에스크로 및 TPM 디스크 암호화를 RHEL(Red Hat Enterprise Linux)을 실행하는 시스템의 NBDE와 비교합니다.
다음 표에는 위협 모델과 각 암호화 솔루션의 복잡성과 관련된 몇 가지 장단점이 표시되어 있습니다.
| 시나리오 | 키 에스크로 | TPM 디스크 암호화 (Clevis 제외) | NBDE |
|---|---|---|---|
| 단일 디스크 도난으로부터 보호 | X | X | X |
| 전체 서버 도난으로부터 보호 | X | X | |
| 시스템은 네트워크와 독립적으로 재부팅 가능 | X | ||
| 주기적인 키 재입력 없음 | X | ||
| 키가 네트워크를 통해 전송되지 않음 | X | X | |
| OpenShift에서 지원 | X | X |
17.1.1.1. 키 에스크로
키 에스크로는 암호화 키를 저장하는 기존 시스템입니다. 네트워크의 키 서버는 암호화된 부팅 디스크가 있는 노드의 암호화 키를 저장하고 쿼리할 때 이를 반환합니다. 키 관리, 전송 암호화 및 인증에 대한 복잡성으로 인해 부팅 디스크 암호화를 위한 합리적인 선택이 아닙니다.
RHEL (Red Hat Enterprise Linux)에서 사용할 수 있지만 키 에스크로 기반 디스크 암호화 설정 및 관리는 수동 프로세스이며 노드 자동 추가를 포함하여 OpenShift Container Platform 자동화 작업에 적합하지 않으며 현재 OpenShift Container Platform에서는 지원되지 않습니다.
17.1.1.2. TPM 암호화
신뢰할 수 있는 TPM(Platform Module) 디스크 암호화는 데이터 센터나 원격 보호 위치에 설치하는 데 가장 적합합니다. dm-crypt 및 BitLocker와 같은 전체 디스크 암호화 유틸리티는 TPM 바인드 키를 사용하여 디스크를 암호화한 다음 노드의 마더보드에 연결된 TPM에 TPM 바인드 키를 저장합니다. 이 방법의 주요 이점은 외부 종속성이 없으며 노드는 외부 상호 작용 없이 부팅 시 자체 디스크를 암호 해독할 수 있다는 것입니다.
디스크가 노드에서 도난되어 외부에서 분석되는 경우 TPM 디스크 암호화는 데이터의 암호 해독을 방지합니다. 그러나 안전하지 않은 위치의 경우 이것으로 충분하지 않을 수 있습니다. 예를 들어 공격자가 전체 노드를 압축하는 경우 노드가 자체 디스크를 암호 해독하므로 공격자는 노드의 전원을 켤 때 데이터를 가로챌 수 있습니다. 물리적 TPM2 칩이 있는 노드와 VPM(Virtual Trusted Platform Module) 액세스 권한이 있는 가상 머신에 적용됩니다.
17.1.1.3. NBDE(Network-Bound Disk Encryption)
NBDE(Network-Bound Disk Encryption)는 네트워크 전체에서 안전하고 익명의 방식으로 암호화 키를 외부 서버 또는 서버 집합에 효과적으로 연결합니다. 노드가 암호화 키를 저장하지 않거나 네트워크를 통해 전송하지 않지만 유사한 방식으로 작동한다는 점에서 키 에스크로가 아닙니다.
Clevis 및 Tang은 네트워크 바인딩 암호화를 제공하는 일반 클라이언트 및 서버 구성 요소입니다. RHCOS(Red Hat Enterprise Linux CoreOS)는 Linux 통합 키 설정(LUKS)과 함께 이러한 구성 요소를 사용하여 root 및 root가 아닌 스토리지 볼륨을 암호화하고 암호 해독하여 네트워크 바인딩 디스크 암호화(Network-Bound Disk Encryption)를 수행합니다.
노드가 시작되면 암호화 핸드셰이크를 수행하여 미리 정의된 Tang 서버 집합에 연결을 시도합니다. 필요한 수의 Tang 서버 수에 도달할 수 있는 경우 노드는 디스크 암호 해독 키를 구성하고 디스크를 잠금 해제하여 계속 부팅할 수 있습니다. 네트워크 중단 또는 서버를 사용할 수 없으므로 노드가 Tang 서버에 액세스할 수 없는 경우 노드는 부팅할 수 없으며 Tang 서버를 다시 사용할 수 있을 때까지 무기한 다시 시도합니다. 키가 네트워크에 있는 노드에 효과적으로 연결되기 때문에, 공격자가 미사용 데이터에 액세스하려고 하면 노드의 디스크와 Tang 서버에 대한 네트워크 액세스도 가져와야 합니다.
다음 그림은 NBDE의 배포 모델을 보여줍니다.
다음 그림은 재부팅 중에 NBDE 동작을 보여줍니다.
17.1.1.4. 보안 공유 암호화
Shamir의 비밀 공유(sss)는 안전하게 키를 분할, 배포 및 재조정하기 위한 암호화 알고리즘입니다. OpenShift Container Platform은 이 알고리즘을 사용하여 더 복잡한 키 보안 조합을 지원할 수 있습니다.
여러 Tang 서버를 사용하도록 클러스터 노드를 구성하면 OpenShift Container Platform은 sss를 사용하여 지정된 서버 중 하나를 사용할 수 있는 경우 성공하는 암호 해독 정책을 설정합니다. 추가 보안을 위해 계층을 만들 수 있습니다. 예를 들어 OpenShift Container Platform에 디스크 암호 해독을 위해 지정된 Tang 서버 목록 중 하나와 TPM이 모두 필요한 정책을 정의할 수 있습니다.
17.1.2. Tang 서버 디스크 암호화
다음 구성 요소와 기술은 NBDE(Network-Bound Disk Encryption)를 구현합니다.
그림 17.1. LUKS1 암호화 볼륨을 사용할 때의 NBDE 스키마입니다 luksmeta 패키지는 LUKS2 볼륨에 사용되지 않습니다.
Tang은 데이터를 네트워크 상에 바인딩하는 서버입니다. 그러면 노드가 특정 보안 네트워크에 바인딩될 때 데이터를 포함하는 노드를 사용할 수 있습니다. Tang은 상태 비저장이며 TLS(전송 계층 보안) 또는 인증이 필요하지 않습니다. 키 서버가 모든 암호화 키를 저장하고 모든 암호화 키에 대한 지식이 있는 에스크로 기반 솔루션과 달리 Tang은 노드 키와 상호 작용하지 않으므로 노드에서 식별 정보를 얻을 수 없습니다.
Clevis는 Linux Unified Key Setup-on-disk-format(LUKS) 볼륨의 자동 잠금 해제를 제공하는 자동화된 암호 해독을 위한 플러그형 프레임워크입니다. Clevis 패키지는 노드에서 실행되며 기능의 클라이언트 측면을 제공합니다.
Clevis 핀 은 Clevis 프레임워크에 대한 플러그인입니다. 다음 세 가지 고정 유형이 있습니다.
- TPM2
- 디스크 암호화를 TPM2에 바인딩합니다.
- Tang
- 디스크 암호화를 Tang 서버에 바인딩하여 NBDE를 활성화합니다.
- Shamir의 시크릿 공유 (sss)
다른 핀의 더 복잡한 조합을 허용합니다. 다음과 같은 더 미묘한 정책을 허용합니다.
- 이 세 개의 Tang 서버 중 하나에 연결할 수 있어야합니다.
- 이 5 개의 Tang 서버 중 세 개에 연결할 수 있어야합니다.
- TPM2 및 이 세 Tang 서버 중 하나 이상에 연결할 수 있어야합니다.
17.1.3. Tang 서버 위치 계획
Tang 서버 환경을 계획할 때 Tang 서버의 실제 및 네트워크 위치를 고려하십시오.
- 물리적 위치
Tang 서버의 지리적 위치는 무단 액세스 또는 도난으로부터 적절하게 보호되고 중요한 서비스를 실행하는 데 필요한 가용성과 접근성을 제공하는 한 비교적 중요하지 않습니다.
항상 Tang 서버를 사용할 수 있는 한 Clevis 클라이언트가 있는 노드에는 로컬 Tang 서버가 필요하지 않습니다. 재해 복구에는 위치에 관계없이 Tang 서버에 대한 중복 전원 및 중복 네트워크 연결이 필요합니다.
- 네트워크 위치
Tang 서버에 대한 네트워크 액세스 권한이 있는 노드는 고유한 디스크 파티션 또는 동일한 Tang 서버에서 암호화된 다른 디스크를 해독할 수 있습니다.
지정된 호스트에서 네트워크 연결 여부가 있는지 확인하는 Tang 서버의 네트워크 위치를 선택하여 암호 해독 권한을 허용합니다. 예를 들어 방화벽 보호는 모든 유형의 게스트 또는 공용 네트워크에서 액세스하지 못하거나, 보안이 유지되지 않은 모든 네트워크 파이크에서 액세스하지 못하도록 할 수 있습니다.
또한 프로덕션 네트워크와 개발 네트워크 간의 네트워크 분리를 유지 관리합니다. 이를 통해 적절한 네트워크 위치를 정의하고 추가 보안 계층을 추가할 수 있습니다.
동일한 리소스(예: 동일한
rolebindings.rbac.authorization.k8s.io클러스터)에 Tang 서버를 배포하지 마십시오. 그러나 Tang 서버 및 기타 보안 리소스의 클러스터는 여러 추가 클러스터 및 클러스터 리소스를 지원하는 데 유용한 구성일 수 있습니다.
17.1.4. Tang 서버 크기 조정 요구사항
가용성, 네트워크 및 물리적 위치에 대한 요구 사항은 서버 용량에 대해 우려하지 않고 사용할 Tang 서버 수를 결정하는 데 영향을 미칩니다.
Tang 서버는 Tang 리소스를 사용하여 암호화된 데이터 상태를 유지 관리하지 않습니다. Tang 서버는 완전히 독립적이거나 중요한 자료만 공유하므로 확장이 용이합니다.
Tang 서버는 핵심 자료를 처리하는 두 가지 방법이 있습니다.
여러 Tang 서버는 주요 자료를 공유합니다.
- 동일한 URL 뒤에서 키를 공유하는 Tang 서버를 로드 밸런싱해야 합니다. 구성은 라운드 로빈 DNS만큼 간단하거나 물리적 로드 밸런서를 사용할 수 있습니다.
- 단일 Tang 서버에서 여러 Tang 서버로 확장할 수 있습니다. Tang 서버가 주요 자료와 동일한 URL을 공유하는 경우 Tang 서버 확장은 노드에서 다시 키 또는 클라이언트 재구성을 필요로 하지 않습니다.
- 클라이언트 노드 설정 및 키 순환에는 Tang 서버 한 개만 필요합니다.
여러 Tang 서버는 자체 주요 자료를 생성합니다.
- 설치 시 여러 Tang 서버를 구성할 수 있습니다.
- 로드 밸런서 백그라운드에서 개별 Tang 서버를 확장할 수 있습니다.
- 모든 Tang 서버는 클라이언트 노드 설정 또는 키 교체 중에 사용할 수 있어야 합니다.
- 클라이언트 노드가 기본 구성을 사용하여 부팅되면 Clevis 클라이언트는 모든 Tang 서버에 연결합니다. 해독을 진행하려면 n 개의 Tang 서버만 온라인 상태 여야합니다. n의 기본값은 1입니다.
- Red Hat은 Tang 서버의 동작을 변경하는 설치 후 구성을 지원하지 않습니다.
17.1.5. 로깅 고려 사항
Tang 트래픽의 중앙 집중식 로깅은 예기치 않은 암호 해독 요청과 같은 항목을 탐지할 수 있기 때문에 유용합니다. 예를 들면 다음과 같습니다.
- 부팅 시퀀스에 해당하지 않는 암호의 암호 해독을 요청하는 노드
- 알려진 유지 관리 활동 외부에서 암호 해독을 요청하는 노드(예:암호 키)
