6.7. 블록 스토리지

블록 스토리지 장치를 초기화하는 방법에는 여러 가지가 있습니다. 기존 접근 방식은 lvm_type 을 thin로 설정한 다음 volume_ clear 매개 변수를 사용하는 것입니다. 또는 볼륨 암호화 기능이 us ed이면 볼륨 암호화 키가 삭제되면 볼륨 삭제가 필요하지 않습니다.

volume_ clear 매개 변수는 인수로 0 또는 shred 를 허용할 수 있습니다. 0 은 하나의 장치에 0을 전달합니다. 분할된 작업은 미리 결정된 비트 패턴의 세 가지 전달을 작성합니다.

구성 파일에는 구성 요소의 원활한 작동에 필요한 중요한 매개 변수 및 정보가 포함되어 있습니다. 의도하거나 실수로 권한이 없는 사용자가 매개 변수 또는 파일 자체를 수정하거나 삭제하면 심각한 가용성 문제로 인해 다른 최종 사용자에게 서비스가 거부됩니다. 따라서 이러한 중요한 구성 파일의 사용자 소유권을 root로 설정하고 그룹 소유권을 cinder 로 설정해야 합니다.

cinder 그룹은 호스트에 없습니다. ls -l 을 사용하면 그룹 소유자의 GID가 표시됩니다.

sudo ls -l /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
-rw-r-----. 1 root 42407 188012 Dec 11 09:34 /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
root UNKNOWN

sudo ls -l /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
-rw-r-----. 1 root 42407 188012 Dec 11 09:34 /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
root UNKNOWN

다음 명령으로 cinder.conf 구성 파일의 사용자 및 그룹 소유권이 각각 root 및 cinder로 설정되어 있는지 확인합니다.

sudo docker exec -it cinder_api stat -L -c "%U %G" /etc/cinder/cinder.conf
root cinder

sudo docker exec -it cinder_api stat -L -c "%U %G" /etc/cinder/cinder.conf
root cinder

cinder.conf 구성 파일에 대한 권한이 640 또는 stricter로 설정되어 있는지 확인합니다.

stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

/var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf 에서 [DEFAULT] 섹션 아래의 auth_strategy 값이 keystone 으로 설정되어 있고 noauth 가 아닌 auth_strategy 값이 설정되어 있는지 확인합니다.

/var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf 에서 [keystone _authtoken] 섹션 아래의 auth_ uri 값이 https:// '로 시작하는 ID API 엔드포인트로 설정되어 있으며 [keystone_authtoken] 아래의 'insecure ] 도 False 로 설정되어 있는지 확인합니다.

cinder.conf 에서 [DEFAULT] 섹션 아래의 glance_api_servers 값이 https:// 로 시작하는 값으로 설정되어 있는지 확인하고, glance_api_insecure 매개 변수의 값이 False 로 설정되어 있는지 확인합니다.

요청당 최대 본문 크기가 정의되지 않은 경우 공격자는 대규모의 임의의 OSAPI 요청을 작성할 수 있으므로 서비스가 충돌하고 결국 서비스 거부 공격이 발생합니다. t를 최대값으로 할당하면 악의적인 과다 크기 요청으로 인해 서비스의 지속적인 가용성이 차단됩니다.

cinder.conf 의 [oslo _middleware] 섹션 아래의 max_ request_body_size 가 114688 로 설정되어 있는지 확인합니다.

암호화되지 않은 볼륨 데이터를 사용하면 공격자가 다양한 VM의 데이터를 읽을 수 있으므로 볼륨 호스팅 플랫폼이 공격자의 가치를 높입니다. 또한 물리적 저장 매체 cou ld는 다른 시스템에서 도난, 다시 마운트 및 액세스합니다. 볼륨 데이터 및 볼륨 백업을 암호화하면 이러한 위험을 완화하고 볼륨 호스팅 플랫폼에 대한 심층적인 방어를 제공할 수 있습니다. 블록 스토리지(c 인더)는 디스크에 기록되기 전에 볼륨 데이터를 암호화할 수 있으므로 볼륨 암호화를 활성화하고 개인 키 스토리지에 Barbican을 사용하는 것이 좋습니다.