표적:(대부분) 여러 볼륨을 사용한 전체 디스크 암호화(일부는 독립적으로 암호화됨)
이유:암호화는 부팅되지 않은 디스크를 보호하지만 연중무휴 시스템의 경우 올바른 상황에서는 많은 보안을 제공하지 않습니다. 또한 인증된 사용자에게 일부 데이터가 필요하지 않은 경우에도 해당 데이터를 오프로드하고 안전하게 유지하는 것이 바람직합니다.
가능한 해결책:
LVM의 다중 LUKS
- 단점: 작동해야 하지만 종종 무분별하고 복잡합니다.
LUKS의 LVM + LUKS의 LVM이 있는 별도의 파티션
- 단점: 파티션이 있으면 LVM의 유연성 이점이 줄어듭니다.
일부 볼륨이 LVM-on-LUKS-on-LVM-on-LUKS인 LUKS의 LVM, 즉 이중 암호화
- 단점: 이중 암호화는 성능에 영향을 미칠 수 있습니다. 또한 복잡/혼란스럽습니다. 그러나 LVM의 유연성은 유지됩니다.
다음 중 어떤 옵션이 가장 좋을까요?
이중 암호화로 인해 성능 저하가 얼마나 발생합니까? hdparm -t결과는 SATA SSD의 암호화되지 않은 볼륨, 암호화된 볼륨 또는 이중 암호화된 볼륨 간의 디스크 읽기에 차이가 없음을 보여주었습니다.
다른 해결책이 있나요?
답변1
대부분 의견에 기반한 내용이라 답변이 어렵습니다. LUKS의 LVM과 LVM의 LUKS 중 어느 것이 더 나은지 물어볼 수도 있습니다. 어느 쪽이든 작동하며 특정 요구 사항에 더 적합할 수 있습니다.
독립형 LUKS 컨테이너의 경우 LVM -> LUKS는 확실히 LUKS -> LVM보다 더 흥미롭게 들리지만 LVM 메타데이터가 암호화되지 않고 논리 볼륨 이름, 크기, 생성 시간 등이 정보를 유출할 수 있다는 단점이 있습니다.
이중 암호화에는 확실히 성능 저하가 따릅니다(AES-NI의 경우에도). 그러나 일부 사용 사례에서는 여전히 괜찮습니다. CPU가 매우 유휴 상태이므로(초강력 데스크톱 시스템에서는 일반적임) 차이를 느끼지 못할 수도 있고, 이중 암호화된 데이터가 성능에 중요하지 않을 수도 있습니다.
아마도 이 작업을 마치게 될 것입니다. 이미 LUKS -> LVM이 있으므로 다른 암호화 레이어가 필요한 경우 LUKS -> LVM -> LUKS입니다. 대신에 다른 LV를 만들고 LUKS에 넣는 것이 더 쉽고 안전하기 때문입니다. 예를 들어 별도의 LUKS 파티션을 위한 공간을 만들기 위해 PV를 축소합니다(이러한 스턴트를 수행할 때 문제가 발생할 수 있음).
그러나 나는 LVM 내부의 LVM의 요점을 잘 이해하지 못하기 때문에 그 위에 또 다른 LVM 레이어를 놓지 않을 것입니다. 그래서 저는 LUKS -> LVM -> LUKS가 끝입니다.
이론적으로 이중 암호화 없이도 이중 암호화 설정이 가능합니다. 즉, 장치 매퍼를 사용하면 내부 LUKS 컨테이너가 데이터를 두 번 암호화할 필요 없이 외부 장치에 직접 전달할 수 있습니다. 장치 매퍼는 이를 달성할 수 있을 만큼 강력해야 하지만 LVM 및 cryptsetup은 거의 확실하게 이러한 기능을 지원하지 않습니다.