注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

身元を保護する

身元セキュリティのベストプラクティス

Palantir Foundry へのアクセスにシングルサインオンのアイデンティティプロバイダ(IdP)を使用する場合、守るべきセキュリティのベストプラクティスがあります。

強力な多要素認証(MFA)を使用する

Palantir では、ユーザー名とパスワードの従来の使用法を超えた証明方法を強く推奨しています。多要素認証は、当社のソフトウェア製品には必須です。独自のアイデンティティプロバイダで多要素認証を実装している場合、強力な認証方法を要求する必要があります。

強力な認証方法の例(おおよその優先順位順):

  • FIDO2互換の USB セキュリティトークン(例:YubiKey、Google Titan)や CAC スマートカードなどの接続型ハードウェアトークン
  • RSA SecurID、Thales SafeNet などのワンタイムパスワード(OTP)トークンジェネレーターなどの切断型ハードウェアトークン
  • Microsoft Authenticator、Google Authenticator などの携帯端末認証アプリケーション
    • 携帯端末でのプッシュ通知よりも OTP ジェネレーターの利用が好ましい
  • Apple Touch ID や Face ID、Windows Hello などの指紋認証や顔認証などの生体認証

SMS ベースの OTP(テキストメッセージ)、メール OTP、2 ステップ認証(リンクをクリックする)、セキュリティ質問などの他の多要素認証は、強力な認証方法とは見なされず、他の方法に切り替えるべきです。

アイデンティティプロバイダに多要素認証が必須でない場合、当社の製品は多要素認証をネイティブでサポートしています。

定期的な再認証を要求する

Palantir Foundry は、アイデンティティプロバイダに対して定期的な再認証を強制するため、意図的に比較的短い最大セッション寿命を設定しています。セッショントークンは攻撃者に盗まれ、その期間中に悪用される可能性があるため、すべてのユーザーセッションに対して比較的短い寿命を強制することで、悪用が時間制限されることを保証します。

同様の理由で、アイデンティティプロバイダによって生成されたセッショントークンの寿命が過度に許容されることがないようにする必要があります。

ゼロトラストセキュリティ原則を実装する

最新のアイデンティティプロバイダを使用している場合、ゼロトラスト技術および戦略を有効にし、使用する必要があります。これらの技術には、条件付きアクセス、デバイスの健全性またはポスチャ評価、強力な多要素認証の主張、関連するコントロールが含まれる場合があります。使用可能な機能やそれらの実装方法については、アイデンティティプロバイダのドキュメントを参照してください。

ゼロトラストセキュリティモデルのベストプラクティスには、以下が含まれます。

  • ソフトウェアベースのマシン証明書、1 要素認証、ネットワークの位置など、弱いセキュリティ指標に基づいてデバイスやユーザーを信頼しない。
  • ユーザーやデバイスを必須のセキュリティコントロールから除外しない。
  • 機密性の高いリソースへのアクセスに、最近の強力な多要素認証を必要とする。
  • デバイスのセキュリティや健全性の証明または評価を、アクセス条件として必要とする。
  • 通常と異なるログオンやアクティビティに対して再認証を求める。

サービスアカウントの管理を厳格化する

サービスアカウントは、機密データへの広範囲なアクセス権を持つことが多く、通常のユーザーアカウントに比べてセキュリティが低いことが多いため、攻撃者にとって魅力的なターゲットとなります。

サービスアカウント管理の落とし穴には以下のようなものがあります。

  • サービスアカウントに複数の人がアクセスできる場合があります。
  • サービスアカウントに多要素認証が有効になっていない場合があります。
  • 組織を離れた人々の後に、サービスアカウントの資格情報が回転されない場合があります。
  • スクリプトやアプリケーションにサービスアカウントの資格情報やトークンがハードコードされている場合があります。

Palantir Foundry でサービスアカウントを使用する場合、データを保護するためにそれらを適切に保護することが重要です。

サービスアカウント管理のベストプラクティスには以下が含まれます。

  • 各サービスアカウントが文書化され、名前が付けられたオーナーがおり、適切性が定期的にレビューされることを確認する。
  • アイデンティティプロバイダを設定して、サービスアカウントが特定の IP アドレスからのみ認証されるようにする。
  • 可能な場合は、サービスアカウントに対して多要素認証を必要とする。
  • サービスアカウントの資格情報を特権アクセス管理(PAM)ソリューションに格納する。
  • サービスアカウントの資格情報にアクセスするために、複数の認証が必要となるようにする。
  • チームの変更や退職者に応じて、サービスアカウントの資格情報を回転させる。
  • サービスアカウントの動作、ログオン、資格情報を厳密に監視する。

監査ログを監視する

ベストプラクティス

お客様は、自分で監査ログを取得し監視することを強く推奨しています。詳細なガイダンスについては、監査ログの監視を参照してください。

Central Auth

Central Auth は、Palantir が管理する Microsoft Entra ID(Azure AD)アイデンティティプロバイダです。Central Auth は、Palantir 情報セキュリティチームによって管理されており、独自のアイデンティティプロバイダを持っていないお客様や、まだ Foundry とアイデンティティプロバイダを統合していないお客様向けに、セキュリティを最優先した認証ソリューションを提供するように設計されています。

Foundry インストール用のアイデンティティプロバイダがない場合、Central Auth を使用してアクセスを提供できる場合があります。詳細については、Palantir の担当者にお問い合わせください。

Central Auth セキュリティ

Central Auth は、SAML Multipass レルムとして Foundry インストールに統合できます。統合された場合、ユーザーアカウントのプロビジョニングとデプロビジョニングは Palantir が管理します。グループ、マーキング、およびその他のプラットフォームセキュリティ機能は、引き続きユーザーが管理します。

すべての Central Auth アカウントは厳格なセキュリティ制御を満たす必要があります。

  • 高強度のパスワードと強力な多要素認証が必須です。
  • Central Auth ユーザーは、怪しいログオンや動作に基づいて再認証を求められる場合があります。
  • 30 日以上使用されていないアカウントは、予告なしに無効にされる場合があります。