AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
MongoDB Branding Shape
Click here >
Docs Menu

Atlas の承認に関するガイダンス

MongoDB Atlas は、リソースへの堅牢なアクセスを確保するために、さまざまな認可方法をサポートしています。Atlas ではすべてのユーザーに認証が必要です。ユーザーが認証されると、認可によってユーザーのリソースへのアクセス権が決定されます。

Atlas認可を実装する場合は、 ロールベースのアクセス制御 (RBAC) を使用する必要があります。フェデレーティッド ID プロバイダーのユーザー グループを RBAC と併用すると、管理が簡素化されます。

次の推奨事項は、すべての配置パラダイムにおいて、ワークフォース(人間)ユーザーとワークロード(アプリケーション)ユーザーの両方に適用されます。

注意

MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者のセキュリティと運用の優れ性の詳細な内訳については、共有責任モデルを参照してください。

Atlas は、 ユーザー認可の管理を簡素化するために RBAC(Role-Based Access Control、ロールベースのアクセス制御) を使用します。Atlas には、 UIと API を使用して Atlas を管理するために一般的に必要な特定のレベルのアクセスを提供する事前定義されたユーザー ロールが含まれています。管理を簡素化するために、 のロールを IdP グループにマッピングできます。

Atlas クラスターに接続するには、きめ細かなカスタム データベース ロールを使用して、ロールがその機能を実行するために必要なアクセス権に基づいて、きめ細かなスコープ設定を提供します。このアプローチにより、最小権限の原則に従うことができます。

注意

常に、必要最低限の RBAC ロールを割り当ててアクセスを制限するべきです。また、ドメイン制限を使用することもお勧めします。

割り当て可能なロールには、組織レベルとプロジェクト レベルの2種類があります。

組織レベルのロールは、サービス アカウントによって新しいプロジェクトの作成、IAM の管理、請求などのタスクを自動化するために使用されます。プラットフォーム チームのメンバーにも使用できます。

  • Organization Owner ロールは組織全体の設定を変更し、構成を削除する能力があるため、大幅に制限され、人間には割り当てられない必要があります。このロールは、組織の最初の設定と構成 のためにのみ使用するサービス アカウントに割り当てる必要があります。初期作成後に構成の変更を最小限に抑えます。アカウントのロックアウトを回避するには、次の項目を作成します。

    • Just-in-Timeアクセスを持つ SAML 組織オーナー グループ。

    • 組織オーナーのロールを持つサービス アカウント。緊急事態に備えて、強力なアクセス マネジメントを備えた安全な場所に保管してください。

  • Organization Member ロールは、組織の設定や構成を表示できる運用およびプラットフォーム チームの管理者向けである必要があります。

  • Organization Project Creator ロールは、開発チームと製品チームの新しいアプリケーションに代わってプロジェクトを作成するために使用されるプログラムによるサービス アカウントです。

  • Organization Billing Admin ロールは、請求APIからプログラムによって請求書を取得し、FinOps ツールに入力するために使用されるプログラムによるサービス アカウントです。このサービス アカウントは、使用状況の報告を担当するリンクされた組織すべてにアクセスできる必要があります。

プロジェクト レベルのロールは、アプリケーション開発と保守を担当する開発チーム、テストチーム、製品チームのためのものです。組織レベルのロールと同様に、常に最小権限の原則に従う必要があります。例として、Project Owner ロールは、運用チームとプロビジョニングチームが実施するガバナンスのためにのみ使用されるべきです。Project Owner はクラスターの作成や削除ができるため、サンドボックス環境で作業している場合をのぞいて、このロールはプログラムによるサービス アカウントに割り当てるべきです。

プロジェクト レベルのロールの詳細については、次を参照してください。

Atlas をフェデレーション IdP と統合することにより、IdP グループを Atlas ロールにマッピングして、ジャストインタイム プロビジョニングを利用できます。これによりアクセス管理が効率化され、プラットフォーム全体で安全で整理されたロール割り当てが保証されます。オーケストレーション レイヤーのプロビジョニング プロセスに基づいて、プログラムでアクセスを許可することができます。

Azure Entra ID、Okta、Ping Identity など、SSO を提供する最新のフェデレーティッド ID プロバイダー(FIP)を使用する必要があります。これにより、認可プロセスの安全性が向上し、IdP グループを Atlas ロールにプログラムで割り当てるために必要な柔軟性がサポートされます。会社のドメインへのアクセスを制限する必要があります。これにより、アクセスが許可されていないユーザーは Atlas にログインできなくなります。

フェデレーション IdP グループへのロールのマッピングについて詳しくは、「ロール マッピング プロセス」を参照してください。

Atlas は、事前定義された時間後に自動的に期限切れとなる一時的なデータベースユーザーの作成をサポートしています。ユーザーを作成できる期間は、6 時間、1 日、または 1 週間です。

詳細については、「データベースユーザーの設定」を参照してください。

認可の設定例については、「認証と認可の例」を参照してください。