본 번역은 검증되지 않았습니다. AIP를 통해 영문원문으로부터 번역되었습니다.

자체 호스팅 Foundry 설치 보호

Palantir Foundry는 클라우드에서 엣지까지 거의 모든 환경에서 안전한 협업을 제공하도록 설계되었습니다. Palantir의 관리형 SaaS 플랫폼 외부에서 Foundry를 실행하는 경우, 예를 들어 자체 데이터센터나 클라우드에서 실행하는 경우, 설치 보호를 위한 다음 지침을 확인 해주세요.

물리적 접근

Foundry 설치가 데이터센터와 같은 베어메탈 하드웨어에 배포된 경우, 강력한 물리적 보안 통제를 구현하는 것이 중요합니다. Foundry를 실행하는 서버에 대한 접근은 승인된 인원으로 제한되어야 하며, 시간 제한 및 문서화된 접근을 따르고 업계 모범 사례를 따라야 합니다.

물리적 보안은 정보 보안의 기초이므로, Foundry를 실행하는 하드웨어에 대한 무단 접근은 적에게 다양한 공격을 수행하고 보안 통제를 무력화할 기회를 제공할 수 있습니다.

데이터 암호화

정보 보안을 유지하기 위해 데이터는 저장 시전송 중 모두 암호화되어야 합니다.

저장 시 데이터

Foundry의 모든 데이터는 애플리케이션 수준 암호화를 통해 저장 시 암호화되지만, Foundry 설치에 사용되는 모든 기본 서버와 저장 장치를 암호화해야 합니다.

  • 전체 디스크 암호화를 위해 업계 표준 암호화 솔루션을 사용해야 합니다. 여기에는 오픈 소스 프로젝트(LUKS ↗와 같은), 상용 소프트웨어, 자체 암호화 드라이브와 같은 하드웨어 구현, 또는 클라우드 서비스 제공업체가 제공하는 솔루션이 포함될 수 있습니다.
  • 암호화 키 자료는 하드웨어 보안 모듈(HSM)과 같은 하드웨어에 저장해야 합니다.
  • 디스크 암호화를 위해 AES-256 또는 AES-128과 같은 강력한 암호화 표준을 사용해야 합니다.

전송 중 데이터

클라이언트와 Foundry 간에 전송되는 모든 데이터는 강력한 암호화 프로토콜과 암호를 사용하여 보호되어야 합니다.

  • 신뢰할 수 있는 인증 기관에서 발급한 유효한 인증서를 사용해야 하며, 인증서의 수명은 90일에서 최대 1년까지 허용됩니다.
  • 전송 계층 보안(TLS) 버전 1.2 이상을 사용하는 연결만 지원해야 합니다.
  • 강력한 TLS 암호 스위트만 지원해야 합니다. 이는 호환성과 보안 요구 사항에 따라 조정해야 합니다.
  • ECDHE와 CHACHA-POLY1305 또는 GCM 모드의 AES-{128-256}을 사용하는 것을 권장합니다. 가능한 경우 CBC 모드 암호 스위트는 피해야 합니다.

아이덴티티 보안

싱글 사인온

싱글 사인온 제공업체에서 중앙 집중적으로 아이덴티티를 관리해야 합니다.

  • 모든 사용자는 명명된 계정을 사용해야 합니다. 계정은 공유되어서는 안 됩니다.
  • 모든 사용자에게 강력한 다중 인증을 요구해야 합니다. 가능한 경우 FIDO2와 같은 최신 기술을 사용해야 합니다. SMS 또는 이메일 기반 다중 인증은 사용하지 않아야 합니다.

자격 증명 위생

사용자에게 강력한 자격 증명 위생을 요구해야 합니다. 비밀번호 없는 인증을 강력히 권장합니다.

  • 사용자가 접근을 위해 충분히 강력하고 길며 고유한 비밀번호를 사용하도록 요구해야 합니다.
  • 사용자가 환경 외부의 다른 서비스와 비밀번호를 재사용하지 않도록 해야 합니다.
  • 사용자가 무단 도메인에 비밀번호를 실수로 입력한 경우 비밀번호를 교체하도록 요구해야 합니다.

제로 트러스트

최신 제로 트러스트 기술을 사용하여 Foundry 설치를 보호해야 합니다.

  • 아이덴티티와 장치 상태 및 검증을 기반으로 승인된 사용자에게만 접근을 허용하기 위해 제로 트러스트 기술을 사용해야 합니다.
  • 신뢰할 수 없거나, 건강하지 않거나, 알려지지 않은 장치에서 Foundry 설치에 대한 접근을 거부해야 합니다.

네트워크 보안

네트워크 분할

Foundry 설치는 환경의 나머지 부분과 고도로 분리되어야 합니다.

  • 방화벽이나 기타 기술을 사용하여 네트워크 격리를 구현해야 합니다. 승인된 프로토콜, 포트 및 서브넷의 허용 목록을 사용하여 서비스에 대한 접근을 제한해야 합니다.
  • Foundry 설치에 대한 모든 인바운드 트래픽을 기본적으로 거부해야 합니다.
  • 가능한 경우 최소한의 네트워크에만 Foundry 설치를 노출해야 합니다. 침입 탐지 시스템 및 웹 애플리케이션 방화벽과 같은 추가 통제가 없는 상태에서 Foundry 설치를 공용 인터넷에 노출하는 것은 권장되지 않습니다.
  • Foundry 설치를 전용 프라이빗 네트워크(VLAN/서브넷)로 분리해야 합니다.

이그레스 제어

Foundry 설치에서 발생하는 네트워크 트래픽은 엄격하게 통제되어야 합니다.

  • Foundry에서의 모든 네트워크 연결이 프록시 또는 기타 네트워크 보안 장치에 의해 제한되도록 요구해야 합니다.
  • Foundry 설치가 연결할 수 있는 IP 또는 도메인별 허용 목록을 유지해야 합니다.
  • Foundry 설치에 의한 다른 모든 네트워크 접근을 거부해야 합니다.

네트워크 보안

Palantir Foundry 설치를 보호하기 위해 네트워크 보안 통제를 사용해야 합니다.

  • 이상 활동을 식별하기 위해 침입 탐지 시스템과 같은 네트워크 보안 통제를 사용해야 합니다.
  • 네트워크 악용 또는 공격 시도를 식별하고 차단하기 위해 방화벽을 사용해야 합니다.
  • 무단 데이터 전송을 탐지하기 위해 데이터 손실 방지(DLP) 기술을 사용해야 합니다.
  • 이상 활동을 식별하기 위해 네트워크에서 네트워크 보안 로그를 수집해야 합니다.

인프라 보안

서버 강화

Foundry 설치에 사용되는 서버는 CIS 또는 NIST 통제와 같은 업계 표준 구성 지침을 사용하여 강화되어야 합니다.

  • 최신의 지원되는 운영 체제만 사용해야 합니다.
  • Foundry 설치에 사용되는 호스트에서 공격적인 취약점 관리 및 패치를 수행해야 합니다. 중요한 보안 취약점은 30일 이내에 패치해야 합니다.

호스트 보안

Foundry 설치를 보호하기 위해 호스트 보안 통제를 사용해야 합니다.

  • 이상 활동을 식별하기 위해 호스트에서 감사 및 보안 로그를 수집해야 합니다.
  • 이상 활동을 식별하기 위해 침입 탐지 시스템과 같은 호스트 기반 보안 통제를 사용해야 합니다.
  • 무단 데이터 전송을 탐지하기 위해 데이터 손실 방지(DLP) 기술을 사용해야 합니다.

특권 접근

Foundry 설치에 대한 특권 접근을 엄격하게 통제해야 합니다.

  • Foundry 설치를 호스팅하는 백엔드 인프라는 전용 배스천 서버 또는 점프 호스트를 통해서만 접근할 수 있도록 제한되어야 합니다.
  • Foundry 설치에 대한 인프라 또는 클라우드 수준 접근에는 다중 인증이 필요합니다.

백업

조직의 연속성을 위해 Foundry 설치의 주기적인 전체 디스크 백업을 수행해야 합니다.

  • Foundry에는 애플리케이션 백업 및 복원을 수행하도록 설계된 서비스("Rescue")가 있습니다.
  • Rescue 서비스 데이터의 전체 디스크 백업을 최소한으로 수행해야 합니다. 모든 Foundry 호스트의 전체 디스크 백업을 수행하는 것이 강력히 권장됩니다.
  • 백업을 암호화하고 내구성 있는 위치 또는 오프라인 위치에 저장해야 합니다. 랜섬웨어 및 기타 악의적인 행위자는 일반적으로 다른 악의적인 행동을 수행하기 전에 백업을 파괴하려고 시도합니다.
  • 백업 및 복원 프로세스를 최소한 연 1회 테스트해야 합니다.

애플리케이션 패치

Foundry 설치에 가능한 한 빨리 보안 패치를 적용해야 합니다.

  • Foundry 설치가 Apollo에 연결된 경우, Foundry 설치는 자동으로 보안 업데이트를 받습니다. 이러한 업데이트는 일반적으로 별도의 조치가 필요하지 않습니다.
  • Apollo를 사용하지 않는 경우, 보안 업데이트가 제공되는 즉시 적용해야 합니다. 중요한 보안 취약점은 30일 이내에 패치해야 합니다.