Linux 파일 시스템을 사용하여 한 번 작성, 많은 읽기 (WORM)


8

나중에 덮어 쓰기, 추가, 업데이트 또는 삭제할 수없는 Linux 파일 시스템에 파일을 작성해야합니다. sudo-er, root 또는 다른 사람이 아닙니다. 기본적으로 전자 문서를 WORM (한 번 작성, 여러 번 읽음) 장치에 기록하도록 요구하는 기록 보관에 대한 금융 서비스 규정 (FINRA 17A-4)의 요구 사항을 충족하려고합니다. DVD 나 값 비싼 EMC Centera 장치를 사용하지 않는 것이 좋습니다.

Linux 파일 시스템이 있습니까, 아니면 SELinux가 파일을 작성한 후 즉시 (또는 최소한) 불변으로 만들 수있는 요구 사항을 지원할 수 있습니까? 아니면 리눅스 권한 등을 사용하여 기존 파일 시스템에서이를 시행 할 수있는 방법을 알고 있습니까?

읽기 전용 권한과 변경 불가능한 속성을 설정할 수 있음을 이해합니다. 물론 루트 사용자가 설정을 해제 할 수있을 것으로 기대합니다.

마운트 해제 한 다음 읽기 전용으로 다시 마운트하는 작은 볼륨에 데이터를 저장하는 것을 고려했지만 루트는 여전히 마운트 해제했다가 다시 쓰기 가능한 것으로 다시 마운트 할 수 있다고 생각합니다.

나는 현명한 아이디어를 찾고 있으며 최악의 시나리오는 이것을 제공하기 위해 기존 파일 시스템을 '향상'하기 위해 약간의 코딩을하고 싶습니다. 좋은 시작점이되는 파일 시스템이 있다고 가정합니다. 이 유형의 네트워크 저장 장치로 작동하도록 신중하게 구성된 Linux 서버를 배치하고 다른 작업은 수행하지 마십시오.

그 후에 파일의 암호화도 유용합니다!


4
당신이 요구하는 것은 할 수 없습니다. 머신에 대한 루트 액세스 권한이 있으면 디스크에서 직접 블록 레벨 작업을 수행 할 수 있습니다. 따라서 어떤 파일 시스템이 최상위에 있든 상관없이 루트로부터 아무것도 보호 할 수 없으며 속도를 늦추거나 보안을 흐리게 보이게 할 수 있습니다.
Regan

SEC 해석 sec.gov/rules/interp/34-47806.htm을 읽은 후 @Regan 에 동의합니다. 그러나이 모든 것이 약간 터무니 없습니다. 예를 들어, 어떻게 CD를 지우나요? 물론 화재로.
Mark Wagner

나는 요구 사항이 '약간 부조리하다'는 것에 동의합니다. 그들은 IT 관리자가 좋지 않은 임원이 요구하는 것에 동의하지 않을 것이라는 진실을 숨기려는 시도가 있었음을 분명히하려고합니다. 큰 디렉토리에서 루트로 삭제하는 것은 누군가에게는 너무 쉬운 일입니다. 물리적 파괴는 SEC의 규칙에 따라 처리 할 수있는 유일한 방법이됩니다.
phil_ayres

chattr + i filename, 파일을 만들 때마다이 명령을 지정해야합니다
c4f4t0r

@ c4f4t0r 중지하지 않습니다 : chattr -i filename그때 rm
phil_ayres

답변:


2

OpenAFS 및 읽기 전용 볼륨을 사용하여이를 수행 할 수 있습니다. 그러나 작동하기 위해 설치해야 할 인프라가 많기 때문에 요구 사항을 충족하지 못할 수 있습니다.

http://www.openafs.org/

기본적으로, 쓰기 가능한 볼륨과 하나 이상의 읽기 전용 볼륨 사본이 있습니다. 쓰기 가능한 볼륨을 해제 할 때까지 읽기 전용 복사본은 클라이언트에서 변경할 수 없습니다. 볼륨을 해제하려면 관리자 권한이 필요합니다.

모든 솔루션에는 특수 하드웨어 또는 특수 하드웨어의 의미를 복제하는 네트워크 파일 시스템이 필요한 것 같습니다.


OpenAFS는 실제로 루트가 읽기 전용 볼륨에 쓰지 못하게합니다. 문서에서 명확한 정의를 찾을 수 없습니다.
phil_ayres

클라이언트의 루트가 ro 볼륨에 쓰지 못하게합니다. 일반적으로 root는 OpenAFS의 특별한 권한을 의미하지 않습니다.
Fred the Magic Wonder Dog

1

사용자 정의 파일 시스템 / 커널 코드를 작성하지 않으면이 작업을 수행 할 수있는 방법이없는 것 같습니다.

실용적인 솔루션은 WORM 아카이브 스토리지 옵션과 함께 Amazon Glacier를 사용하는 것으로 보입니다. https://aws.amazon.com/blogs/aws/glacier-vault-lock/ 의 AWS 공식 블로그에 따르면

[...]이 중요한 레코드 보존 유스 케이스를 지원하도록 설계된 다양한 준수 제어로 볼트를 잠글 수있는 새로운 Glacier 기능. 이제 볼트에서 볼트 잠금 정책을 생성하고 잠글 수 있습니다. 일단 잠겨 있으면 정책을 덮어 쓰거나 삭제할 수 없습니다. Glacier는 정책을 시행하고 여기에 지정된 통제 (사전 정의 된 보존 기간 포함)에 따라 귀하의 기록을 보호합니다.

볼트 잠금 정책을 잠근 후에는 변경할 수 없습니다. 그러나 별도의 볼트 액세스 정책을 사용하여 준수와 관련되지 않은 액세스 제어를 계속 변경하고 구성 할 수 있습니다. 예를 들어, 비즈니스 파트너 또는 지정된 제 3 자 (규정에 따라 필요한 경우)에 대한 읽기 권한을 부여 할 수 있습니다.

저에게는 NetApp 또는 EMC 하드웨어 비용없이 필요한 정보를 정확하게 제공하면서 기록 보존 요구 사항을 충족하는 것처럼 보입니다.


내 솔루션과 논리적 인 차이는 없습니다. 서버 관리자 (이 경우 Amazon)는 여전히 일부 또는 모든 파일을 지우거나 변조 할 수 있습니다. 여기서 유일한 차이점은 파일 스토리지 제공자입니다 ...?
nrc

스토리지 제공 업체가 실제 차이라는 가정하에 정확히 맞습니다. 사내 서버 관리자와 함께, 규제 기관은 동일한 조직의 상급 관리자가 레코드를 삭제하거나 변경하기 위해 조작 할 수 있다고 생각합니다. 물론 아마존의 누군가에게 모든 것을 파기하라고 요청할 수는 있지만, 종이 흔적이있을 것이며 예상치 못한 요청이 거부 될 가능성이 더 높다는 가정이 있습니다. 공식 에스크로만큼 좋지는 않지만 책임을 분리하면 필요한 많은 보호 기능을 제공합니다.
phil_ayres

1
스토리지 비용 지불을 중단하여 파일을 계속 삭제할 수 있습니다.
Tomas Zubiri

0

사용자가 파일을 덮어 쓸 수없는 시스템에서 파일에 액세스해야하는 경우 쓰기 권한이없는 원격 볼륨을 마운트 할 수 있습니다. 이를 수행하는 가장 쉬운 방법은 읽기 전용 samba / cifs 공유를 마운트하는 것입니다.

그렇지 않으면 사용자가 덮어 쓰거나 수정할 수없는 새 파일을 쓸 수있는 방법이 필요한 경우 해결책은 FUSE curlftpfs를 사용하여 FTP 경로를 마운트하는 것입니다.

다음 지시문을 사용하여 proftpd 디렉토리를 설정할 수 있습니다.

AllowOverwrite off
<Limit WRITE>
  DenyAll
</Limit>
<Limit STOR>
  AllowAll
</Limit>

이러한 방식으로 새 파일을 마운트 된 디렉토리에 저장할 수 있지만 더 이상 수정하거나 제거 할 수 없습니다.

링크 : CurlFtpFS , ProFTPD


나는 당신이 말하는 것을 얻었고, 분명히 선택 사항 인 것 같습니다. 그러나 파일 서버의 관리자라면 아무것도 삭제할 수 있습니다. 목표는 관리자 (적어도 실제 드라이브에 액세스 할 수없는 사용자)도 파일을 삭제하지 못하도록하는 것입니다.
phil_ayres

FTP 서버는 저렴한 WORM 장치 역할을합니다. 그러나 원격 FTP 서버의 관리자는 파일에 액세스하여 파일을 변경할 수 있습니다. 해결책은 시스템 관리자가 파일을 엉망으로 만들 수 없도록 비대칭 키 시스템으로 파일을 생성 할 때 서명하는 것입니다. 관리자는 여전히 파일을 지울 수 있지만 더 이상 파일을 통지하지 않고 수정할 수는 없습니다.
nrc

불행히도 SEC 규정에 따르면 변조를 시연하기 위해 파일에 서명하는 것만으로는 충분하지 않습니다. 따라서 파일을 완전히 변경할 수 없게 만드는 것에 대한 질문입니다.
phil_ayres

0

이는 " 무적 백업 "문제 의 변형 이며이를 구현할 수있는 유일한 방법은 체크섬을 사용 및 공유하고 물리적 또는 관리 액세스를 공유하지 않는 여러 원격 웜 파일 시스템을 사용하는 것입니다. 이를 통해 모든 것이 한 번 작성되고 복제되며 무결성이 보장되며 단일 블록이 지워지거나 변경되거나 손상되거나 복구 가능한 경우가 보장됩니다.

Plan9 또는 그 파생 상품이 필요한 모든 기능을 암시 할 수 있습니다. Plan9Venti 참조

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.