「プロジェクトにクラスター作成権限を渡すと、誰かが必ずGDPR違反のリージョンにデプロイしてしまう」
エンタープライズ規模でMongoDB Atlasを運用するプラットフォームチームは、このジレンマに直面してきました。ロールベースアクセス制御（RBAC）は「誰が何をできるか」を制御できますが、「どんな条件で実行するか」には対応できません。
MongoDBは2025年から、この問題をCedarベースのResource Policiesで解決しています。2026年2月には機能が拡張され、現在1,562以上の組織が導入済みです。
この記事でわかること：
- なぜRBACだけでは大規模運用に限界があるのか
- CedarというAWS開発の認可エンジンが何を解決するのか
- Atlas Resource Policiesで実際に何を制御できるか
- RBACのアクセス拒否とCedarポリシー違反の違い
RBACが対応できない「条件付き制約」
RBACは「プロジェクトクラスターマネージャー」などのロールを通じて操作権限を管理します。しかしロールが答えるのは「この人は操作できるか」という問いだけです。「このクラスターはEU圏内にのみデプロイできるか」「TLSバージョンは1.2以上か」といった設定条件の検証は、RBACの設計範囲外にあります。
MongoDBが実際に観察したパターンを見ると、問題の深さがわかります。クラスター作成権限を委譲したとたん、開発者が非準拠リージョンにデプロイする、0.0.0.0/0のワイルドカードIPでデータベースをインターネットに晒す、古いTLSバージョンを使ってセキュリティ監査に引っかかる、といった事態が起きていました。
この問題をロールの細分化で解決しようとすると、クラウドプロバイダー・リージョン・設定条件の組み合わせが数百〜数千になり、管理が破綻します。かといってアプリケーションコードにバリデーションを埋め込むと、ポリシー変更のたびにデプロイが必要になります。
CedarとはAWSが開発した認可エンジン
Cedarは2023年にAWSがオープンソース化した認可ポリシー言語とその評価エンジンです。RustとWebAssemblyで実装されており、GitHubリポジトリは公開から3年で1,400以上のスターを獲得しています。AWSのAmazon Verified Permissionsにも採用されており、AWS内部のマルチテナントサービスで本番実績があります。
Cedarの特徴は以下の3点です。
人間が読める宣言型構文を持ちます。ポリシーはテキストファイルとして管理でき、GitでバージョニングしてTerraformと同じワークフローでレビューできます。
RBAC（ロールベース）とABAC（属性ベース）の両方に対応します。「誰がどんな操作をできるか」と「どんな属性を持つリソースに対して実行できるか」を1つの言語で表現できます。
数学的な検証が可能な設計です。ポリシーの論理的矛盾を事前に検出できるため、デプロイ前に意図しない許可・拒否を発見できます。VS Code拡張やCLIツール、テストフレームワークも整備されています。
Atlas Resource Policiesで制御できること
MongoDBがCedarを採用して実装したのが「Atlas Resource Policies」です。組織オーナーが設定したポリシーは、配下の全プロジェクト・クラスターに即時適用されます。
現在制御できる主な項目は次のとおりです。
地理的制限: GDPRやデータ主権の要件に合わせて、クラスターを特定のリージョンに限定できます。例えばEU顧客向けデプロイをEUリージョン専用に強制できます。
ネットワークセキュリティ: ワイルドカードIP（0.0.0.0/0）のアクセスリスト追加を組織全体で禁止できます。パブリックネットワーク経由のアクセスを完全に遮断する設定も可能です。
TLS設定の強制: 最小TLSバージョン（1.2以上）や暗号スイートの指定を強制できます。古い設定を使い続けるクラスターを組織レベルで排除できます。
クラスタースペックの制限: クラスタータイヤの上限・下限を設定してコスト管理に使えます。オートスケーリングも上限ポリシーで制御できます。
クラウドプロバイダーの制限: AWSのみ、あるいはAWS+Google Cloudのみといったプロバイダー制限を設定できます。
2026年2月の更新では、シャーデッドクラスターに専用コンフィグサーバーを必須化するポリシーも追加されました。今後はデータベース認証方式の強制、保存時暗号化への顧客管理キーの必須化、Atlas Searchデプロイの制御が追加予定です。
RBACのエラーとCedarのエラーの違い
RBACで操作が拒否された場合、ユーザーが受け取るメッセージは「権限がありません」という通知だけです。なぜ拒否されたのか、どの権限が必要なのか、エラーからは読み取れません。
Cedarポリシー違反の場合は異なります。「us-east-1とus-west-2以外のリージョンへのデプロイを禁じるポリシーXXXに違反しています」というメッセージが返ります。違反したポリシーのIDと理由が明示されるため、開発者は何を変更すれば通るのかを即座に把握できます。
この設計はMongoDBの製品思想を反映しています。「不透明な権限で制限するのではなく、明確な制約で自由を与える」という方針です。開発者は引き続きセルフサービスでインフラをプロビジョニングでき、プラットフォームチームはセキュリティ境界を維持できます。
AI時代の認可設計として
MongoDBはAWSのブログ投稿の中で、Cedarの採用がAI時代に特に重要だと説明しています。現代のアプリケーションはトランザクションDBに加えてベクターインデックス、RAGパイプライン、ストリーミングフローが組み合わさっており、ガバナンスの境界が複雑化しています。インフラ変更の頻度も上がっており、コードに埋め込んだ認可ロジックは脆くなりやすい、という指摘です。
ポリシーをコードから分離し、宣言的に管理する設計は、変化の速いAIアプリ開発環境での運用統制に向いています。MongoDB Atlasは自社の認証基盤にCedarを採用することで、このパターンを大規模マルチテナント環境で実証しました。
Atlas Resource Policiesの設定方法はMongoDB公式ドキュメントで確認できます。Cedar言語の仕様はGitHub（cedar-policy/cedar）と公式サイト（docs.cedarpolicy.com）で公開されており、ポリシープレイグラウンドで事前テストも可能です。