Linux : LUKS 및 여러 하드 드라이브

RAID-1 시스템 암호화 장치 (LUKS의 LVM)에 Debian Linux 시스템 (amd64)이 설치되어 있고 데이터를 넣을 디스크 (LUKS 및 LVM)가> = 4 인 RAID-6이 있습니다.

기본 아이디어는 로컬 또는 ssh를 통해 부팅 할 때 시스템 암호화 파티션의 잠금을 해제하고 RAID-6 암호화 파티션의 / etc / crypttab에 키 파일을 저장하는 것입니다. 보안 위험이 있습니까? 내 말은 ... 누군가 로컬 / 원격으로 내 시스템에 들어갈 수 있다면 "루팅"(예 : SSH)에 취약한 서버에서 많은 서비스가 실행되고 있다고 생각합니다. 대안이 있습니까 (SSH를 통해 파티션을 잠금 해제하는 것 외에는 데이터 파티션이 마운트되기 전에 백업 작업이 시작되기 때문에 문제가 될 수 있음).

다른 컴퓨터에서는 백업용 LUKS + 회색 구멍 (RAID-6 없음)이있는 여러 디스크를 사용하고 동일한 암호의 10 배를 입력하여 10 개의 디스크를 잠금 해제하는 것은 정말 어려울 것입니다 ...

— 사용자
소스

누군가 시스템에 침입하여 루트가 될 수 있다면 암호화 된 파티션의 키를 얻을 필요가 없습니다. 루트로부터 보호 할 필요가 없으며 TPM이나 가상 머신에서 실행되는 특수 하드웨어 없이는 불가능합니다.

— Gilles 'SO- 악마 그만'

실례합니다 ? 루트 인 경우에도 LUKS 파티션을 잠금 해제하려면 키 파일 / 암호를 제공해야합니다. 누군가 루트가되면 암호화 된 데이터에 완전히 액세스 할 수 있다고 가정합니다. 안타깝게도 암호화 된 파티션을 마운트 한 후에는 암호화 여부에 따라 차이가 없기 때문에 간단합니다. 그렇다면 가상 머신의 장점은 무엇입니까? 그렇다면 왜 암호화가 도움이됩니까? SSH 및 유사한 서비스를 통해 루트에 대한 액세스를 거부하는 유일한 솔루션입니까? 그러나 여전히 해커가 일반 사용자로 시스템에 침입하면 일반적으로 모든 파일에 대한 읽기 권한이 있습니까?

— user51166

정확하게 누군가 누군가 시스템에 뿌리를두고 있다면 모든 것에 액세스 할 수 있습니다. VM은 VM의 모든 항목에 액세스 할 수 있음을 의미 할 수 있습니다. 암호화의 유일한 사용은 누군가가 하드웨어를 훔치는 경우입니다.

— Gilles 'SO- 악마 그만'

예. ...이 경우 데이터를 저장하는 가장 안전한 방법은 모든 네트워크에서 연결이 끊어지고 건물에 통합 된 암호화 된 컴퓨터에 있다고 주장 할 수 있습니다. 그런 다음 여전히 키보드를 사용하여 시스템을 재부팅하지 않고도 데이터를 훔칠 수 있습니다. 백업 서버가 될 것이므로 시스템을 인터넷에서 격리시킬 수도 있으므로 LAN 액세스 만 있으면됩니다. VPN을 사용하거나 LAN 시스템 중 하나가 감염되면 백업 시스템도 노출됩니다. 이 문제를 해결하기 위해 무엇을 하시겠습니까?

— user51166

또한 unix.stackexchange.com/a/110102/50601

— Tim Abell

답변:

당신은 사용할 수 있습니다 /lib/cryptsetup/scripts/decrypt_derived당신에 crypttab자동으로 다른 하나의 디스크에서 키를 사용할 수 있습니다.

이 decrypt_derived 스크립트는 데비안의 cryptsetup 패키지의 일부입니다.

sda6crypt에서 sda5로 키를 추가하는 작은 예 :

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

요즘에는 파일을 삭제하는 것이 매우 어려우므로 / path / to / mykeyfile이 암호화 된 드라이브에 있는지 확인하십시오 ( sda6crypt제 예제에서는 좋은 해결책 일 것입니다).

일반적으로 사용자 공간 파일 시스템 암호화를 사용하여 추가 보안 계층을 추가 할 수 있습니다 (예 : via) encfs.

— 조펠
소스

그렇게하면 키 파일을 디스크에 저장할 필요가 없습니다. 좋을 것입니다. 그러나 문제가 될만한 가치가 있다고 생각하십니까 (즉, 암호화 된 루트 장치에 키 파일을 저장하는 것이 "충분히 안전합니다")? 의심의 여지가 있기 때문에 의견을 묻습니다. 제안 해 주셔서 감사합니다.

— user51166

와 솔루션은 decrypt_derived더 키 파일이 없음을, 유일한 장점이있다. 누군가가 루트 액세스 권한을 얻을 수 있으면 일반적으로 손실됩니다. 침입자가 스크립트를 실행하는 것보다 키 파일을 읽는 것이 조금 더 쉽습니다. 보안을 강화하려면 TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity 등을 사용하여 시스템을 강화할 수 있지만 추가 노력이 필요합니다. 그리고 가치가 있는지에 대한 질문이 더 중요합니다. 키가 파생되거나 저장된 위치에서 드라이브가 충돌하는 경우 키 또는 별도의 키를 백업하는 것을 잊지 마십시오.

— jofel

grsecurity 또는 이와 유사한 소프트웨어도 사용할 계획이었습니다 (시작 시점이 아니라 보안 시간이 필요할 때). 가능한 경우 키 파일이 아닌 암호 만 사용하려고합니다. 암호는 RAM에 저장되므로 암호에 대해서도 논쟁 할 수 있습니다.

— user51166

전체 파일 시스템을 덮어 쓰지 않고 디스크가 고장 나더라도 키 파일을 어디에서나 삭제할 수있는 좋은 방법은 없습니다. 저널링 파일 시스템은 상황을 크게 악화시키지 않습니다.

— Gilles 'SO- 악마 그만두 다'

@Gilles 안전한 파일 삭제 전문가가 아니기 때문에 답변을 편집했습니다. 키 파일을 암호화 된 드라이브에 저장하는 것이 좋습니다.

— jofel

jofels 답변을 기반으로 여기에 동일한 예제가 있지만 키를 파일에 저장할 필요는 없습니다. 키는 디스크에 아무것도 저장하지 않는 명명 된 파이프로 전달됩니다.

/lib/cryptsetup/scripts/decrypt_derived암호화 탭에서 한 디스크의 키를 다른 디스크에 자동으로 사용할 수 있습니다 . 이 decrypt_derived스크립트는 데비안의 cryptsetup 패키지의 일부입니다.

sda6crypt에서 sda5로 키를 추가하도록 수정 된 예 :

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

이 keyscript옵션 crypttab은 데비안의 원래 cryptsetup 도구로 처리 된 경우에만 작동 하며, 시스템 재 구현은 현재이를 지원하지 않습니다. 시스템에서 systemd (대부분의 시스템)를 사용하는 경우 initramfssystemd를 시작하기 전에 cryptsetup 도구를 사용하여 initrd에서 처리를 강제 실행 하는 옵션 이 필요합니다 .

— 얀카 니스
소스