자체 명명 시스템 SFS

1. SFS 란?

SFS 는 SAN 및 하드웨어와 소프트웨어의 조합에 설치된 파일 시스템 입니다.

다양한 운영 체제 플랫폼을 위한 통합 파일 스토리지 환경을 제공하여 여러 독립 파일 시스템을 공유 파일 시스템으로 추상화함으로써 기존 SAN 아키텍처의 파일 및 데이터 관리 문제를 해결하고 파일 수준을 달성합니다. 데이터 공유, 스토리지 할당 및 Serverless 데이터 백업, SVC 와 마찬가지로 스토리지 장치 구성, 투명 마이그레이션 데이터 및 기타 가상 스토리지 SAN 컨트롤러를 정책에 따라 동적으로 조정하는 기능이 있으며 모든 기능이 파일 주위에 있습니다. 레벨 스토리지 서비스가 배치됩니다. 뿐만 아니라 SFS 는 분산 파일 시스템의 설계 개념과 시스템 아키텍처를 한 단계 더 발전시킵니다. 일반 분산 파일 시스템의 특성 외에도 SAN 을 전체 파일 시스템의 데이터 저장 및 전송 경로로 사용합니다. 이들은 대역외 (out-of-band) 아키텍처를 사용하여 고속 이더넷을 통해 파일 시스템 원시 데이터를 전송하고 이를 전용 원시 데이터 서버로 처리 및 저장합니다. SAN File System 은 시스템 리소스를 효과적으로 활용하고 성능을 향상시키며 비용을 절감 할 수있는 정책 기반 파일 데이터 위치 선택 방법을 채택합니다.

자기 검증 파일 시스템은 David Mazieres 와 그의 스승 인 M. Frans Kaashoek 이 박사 학위 논문에서 제안했습니다. SFS (Self-Certifying File System) 는 인터넷 전체가 공유하는 파일 시스템을 설계하도록 설계되었으며 전역 SFS 시스템은 모두 동일한 네임 스페이스에 있습니다. SFS 에서 파일 공유는 매우 간단 할 수 있습니다. 파일 이름만 입력하면 됩니다. 누구나 웹과 같은 SFS 서버를 구축 할 수 있으며 모든 클라이언트는 네트워크의 모든 서버에 연결할 수 있습니다.

직관적으로 글로벌 공유 파일 시스템을 구현하는데 있어 가장 큰 장애물은 서버가 클라이언트에 인증을 제공하는 방법입니다. 파일 시스템을 사용할 때 사용자는 서버를 익명으로 입력 할 수 있으며 모든 클라이언트는 언제든지 서버를 입력 할 수 있습니다. 그렇다면 문제는 합리적으로 핵심을 관리하는 방법입니다. 우리가 생각할 수있는 한 가지 생각은 각 서버가 비대칭 암호화를 사용하여 개인 키와 공개 키를 생성한다는 것입니다. 클라이언트는 서버의 공개 키를 사용하여 서버의 보안 연결을 확인합니다. 그렇다면 새로운 문제가 있습니다. 클라이언트가 처음에 서버의 공개 키를 얻게하려면 어떻게해야 합니까? 다른 요구 시나리오의 경우 키 관리에 대한 요구 사항이 다르며 키 관리의 확장 성을 달성하는 방법은 무엇입니까?

SFS 는 공개 키 정보를 파일 이름에 포함시키고 ‘자체 검증 파일 이름’ 을 명명하는 새로운 방법을 사용합니다. 따라서 파일 시스템 내에 키 관리를 구현할 필요가 없습니다. 키 관리 기능은 파일 명명에 대한 사용자의 규칙에 추가 될 수 있습니다. 이것은 사용자의 암호화 방법에 많은 편의를 제공하며 사용자는 자신의 필요에 따라 필요한 암호화 방법을 선택할 수 있습니다.

SFS 의 핵심 아이디어는 다음과 같습니다.

SFS 파일 시스템에는 자체 인증 경로 이름이 있으며 파일 시스템 내에서 키 관리가 필요하지 않습니다. 다양한 조합을 포함하여 SFS 에서 다양한 키 관리 메커니즘을 쉽게 설정할 수 있습니다. SFS 는 키 배포에서 키 해지를 분리하고 키 복구를 방지합니다.

2. SFS 디자인

2.1 보안

SFS 시스템의 경우 보안은 두 부분으로 정의 할 수 있습니다. 1) 파일 시스템 자체의 보안, 2) 키 관리의 보안 입니다. 즉, 보안은 공격자가 허가없이 파일 시스템을 읽거나 수정할 수 없다는 것을 의미하며 사용자의 요청에 대해 파일 시스템은 올바른 파일을 사용자에게 반환해야 합니다.

파일 시스템 자체의 보안: 명시적으로 익명 액세스를 허용하지 않는 한 SFS 는 파일을 읽거나, 수정하거나, 삭제하거나, 변조 할 필요가 있는 경우 올바른 키가 필요합니다. 클라이언트는 항상 서버의 암호화 된 보안 채널에서 통신하며 채널은 양 당사자의 ID, 데이터 무결성 및 실시간을 보장해야 합니다. (공격자가 패킷을 가로 채서 시스템을 스푸핑하기 위해 다시 보내지 않도록하십시오. 이를 재연 공격이라고 합니다)

키 관리의 보안: 파일 시스템의 보안만으로는 사용자의 요구를 충족시키지 못합니다. 사용자는 키 관리를 사용하여 보다 높은 수준의 보안을 달성 할 수 있습니다. 사용자는 사전 구성된 개인 키를 사용하거나 다중 암호화를 사용하거나 타사에서 제공하는 파일 시스템을 사용하여 인증 된 파일 서버에 액세스 할 수 있습니다. 사용자는 유연하고 쉽게 다양한 키 관리 메커니즘을 구축 할 수 있습니다.

2.2 확장성

SFS 위치 지정은 전 세계적으로 공유되는 파일 시스템이기 때문에 확장성이 뛰어납니다. 사용자가 암호 인증을 사용하여 개인 파일을 읽거나 공개 서버에서 콘텐츠를 탐색하는 경우 SFS 가 잘 호환되어야 합니다. 새 서버를 배포 할 때 SFS 는 가능한 한 간단하고 편리해야 합니다.

SFS 시스템에서는 인터넷에 도메인 이름이나 주소가 있는 서버를 SFS 서버로 배포 할 수 있으며 등록 권한을 요청하지 않아도 프로세스가 매우 간단합니다. SFS 는 전체 네트워크에 대한 공유 네임 스페이스, 키 관리를 위한 기본 요소 세트 및 모듈 식 디자인이라는 세 가지 특성을 통해 확장된 성능을 구현합니다.

전역 네임 스페이스: 모든 클라이언트에 로그인 되어있는 SFS 는 동일한 네임 스페이스를 사용합니다. SFS 는 모든 클라이언트에서 동일한 파일을 공유하지만 아무도 전체 글로벌 네임 스페이스를 제어 할 수 없으며 모든 사용자가 네임 스페이스에 새 서버를 추가 할 수 있습니다. 키 관리를 위한 기본 세트: SFS 를 사용하면 사용자가 임의의 알고리즘을 사용하여 파일 이름 확인 중에 공개 키를 찾고 확인할 수 있습니다. 서로 다른 사용자가 서로 다른 기술로 동일한 서버를 인증 할 수 있으며 SFS 를 통해 파일 캐시를 안전하게 공유 할 수 있습니다. 모듈형 설계: 클라이언트와 서버는 모듈형으로 설계되었으며 대부분의 프로그램은 설계된 인터페이스를 사용하여 통신합니다. 이렇게하면 시스템의 모든 부분을 업데이트 하거나 새 기능을 추가하는 것이 쉽습니다.

3. 자체 확인 파일 경로

자체 검증 파일 시스템의 중요한 특징은 외부 정보에 의존하지 않고 암호화 제어 권한을 사용하는 것입니다. 이는 SFS 가 로컬 구성 파일을 사용하는 경우 전역 파일 시스템의 디자인과 분명히 상반되기 때문에 중앙 서버가 연결을 지원하는데 사용되는 경우 사용자는 신뢰할 수 없기 때문입니다. 그렇다면 외부 정보에 의존하지 않고 파일 데이터를 안전하게 얻는 방법은 무엇입니까? SFS 는 자가 인증 할 수 있는 경로 이름을 통해 이를 달성 할 수있는 새로운 방법을 제안합니다.

SFS 경로에는 네트워크 주소 및 공개 키와 같이 지정된 서버와의 연결을 형성하는데 필요한 모든 정보가 들어 있습니다. SFS 파일 경로는 세 부분으로 구성됩니다.

서버 위치: IP 주소 또는 DNS 호스트 이름이 될 수있는 파일 시스템 서버의 주소를 SFS 클라이언트에 알립니다. 호스트ID : 서버와의 보안 연결 채널을 구축하는 방법을 SFS 에 알립니다. 연결 보안을 위해 각 SFS 클라이언트에는 공개 키가 있으며 HostID 는 일반적으로 호스트 이름과 공개 키의 해시로 설정됩니다. 일반적으로 SFS 는 SHA-1 함수에 따라 계산됩니다. HostID = SHA-1 (“HostInfo”, Location, PublicKey, “HostInfo”, Location, PublicKey)

SHA-1 의 사용은 주로 계산의 용이함과 허용 가능한 보안 수준을 고려합니다. SHA-1 의 출력은 20 바이트로 고정되어 공개 키보다 훨씬 짧습니다. 동시에 SHA-1 은 SFS 에 대한 충분한 암호화 보호를 제공 할 수 있으며 요구 사항을 충족시키기 위해 한 쌍의 합법적인 서버 위치와 공개 키 쌍을 찾을 수 있습니다.

원격 서버에서 파일의 주소: 처음 두 메시지는 대상 서버를 찾고 보안 연결을 작성하는 것입니다. 마지막으로 파일의 위치를 제공하고 필요한 파일을 찾아야 합니다. 전체 자체 검증 파일 경로의 형태는 다음과 같습니다.

SFS 시스템은 인터넷 주소 또는 도메인 이름을 위치로 제공하고 공개 키 개인 키 쌍이 주어지면 해당 HostID 를 확인하고 SFS 서버 소프트웨어를 실행하며 모든 서버는 SFS 에 추가 할 수 있습니다. 등록 절차를 수행하십시오.

4. 사용자 확인

자체 유효성이 검사 된 경로 이름은 사용자가 서버의 ID 를 확인하는 데 도움을 주며 사용자 인증 모듈은 서버가 어떤 사용자가 합법적인지 확인하는 데 도움이 됩니다. 서버 인증과 마찬가지로 모든 서버에서 작동하는 사용자 인증 방법을 찾는 것도 똑같이 어렵습니다. 따라서 SFS 는 사용자 인증을 파일 시스템과 구분합니다. 외부 소프트웨어는 서버 요구에 따라 사용자를 인증하는 프로토콜을 설계 할 수 있습니다.

클라이언트 측에서는 에이전트가 사용자 인증을 담당합니다. 사용자가 처음 SFS 파일 시스템에 액세스하면 클라이언트는 액세스를 로드하고 에이전트에 이벤트를 알립니다. 그런 다음 에이전트는 원격 서버에 대한 사용자를 인증합니다. 서버 측면에서 이 기능 부분은 서버에서 외부 인증 채널로 이동했습니다. 에이전트와 인증 서버는 SFS 를 통해 정보를 전달합니다. 검증자가 검증 요청을 거절하면 에이전트는 인증 프로토콜을 변경하여 다시 요청할 수 있습니다. 이 방법으로 실제 실제 파일 시스템을 수정하지 않고 새로운 사용자 인증 정보를 추가 할 수 있습니다. 사용자가 파일 서버에 등록되어 있지 않으면 에이전트는 일정 횟수 시도한 후 사용자의 인증을 거부하고 사용자에게 파일 시스템에 대한 익명 액세스 권한을 부여합니다. 또한 에이전트는 여러 프로토콜을 통해 특정 서버에 쉽게 연결할 수 있으며 매우 편리하고 유연합니다.

5. 키 폐기 메커니즘

때때로 서버의 개인 키가 유출 될 수 있으며 원래의 자체 인증 파일 경로가 악의적인 공격자가 설정 한 서버에 잘못 위치 할 수 있습니다. 이를 피하기 위해 SFS 는 키 해지 명령어와 HostID 차단과 같은 두 가지 메커니즘을 제어합니다. 키 해지 명령은 파일 서버 소유자 만 보낼 수 있으며 대상은 모든 사용자입니다. 호스트 ID 차단은 다른 노드에서 보내고 파일 서버 소유자와 충돌 할 수 있습니다. 인증된 각 에이전트는 HostID 차단 명령을 따르거나 준수 할 수 있습니다. 준수하도록 선택하면 해당 HostID 에 액세스 하지 않습니다.

키 해지 명령의 형식: Revoke message = { “PathRevok e”, Location, K, NULL} K^-1 여기서 “PathRevoke” 필드는 상수이고 Location 은 키를 해지해야하는 자체 확인 경로의 이름이고 NULL 은 전달 포인터 명령어의 일관성을 유지하기 위해 전달 포인터로서 여기서 빈 경로를 가리키며 이는 원래 포인터가 유효하지 않음을 의미합니다. 여기서 K 는 실패 이전의 공개 키이고 K^-1 은 개인 키입니다. 이 정보는 해지 지시가 서버 소유자에 의해 발행되도록 합니다.

SFS 클라이언트 소프트웨어가 해지 인증서를 볼 때 해지 주소에 대한 액세스 요청은 모두 금지됩니다. 서버는 다음 두 가지 방법으로 키 해지 명령을받습니다. 1) SFS가 서버에 연결되면 해지 된 주소 또는 경로에 액세스하면 서버에서 반환 한 키 해지 명령을 받게됩니다. 2) 사용자가 처음으로 자체 인증 경로 이름을 수행하면 클라이언트는 에이전트에게 해지되었는지 확인하도록 요청한 다음 에이전트가 해당 결과를 반환합니다. 해지 명령은 자체 유효성 검사이므로 해지 명령을 배포하는 것은 그리 중요하지 않으며 다른 소스에서 보낸 해지 명령을 쉽게 요청할 수 있습니다.

더 자세한 SFS 는 다음을 참조하기 바랍니다. https://pdos.csail.mit.edu/papers/sfs:mazieres-phd.ps.gz