こんにちは、k.katoです。
今回は、サインオン・ポリシーのちょっとした落とし穴についてご紹介します。
これに気がついたきっかけは、ネットワーク・ペリメータによる制御をかけたのに、デフォルト・ドメインのAdministratorsだけ、設定していない接続元IPからログインができてしまったことでした。
実はこれ、デフォルト・ドメイン特有の仕様が原因です。
結論から知りたい方はこちらの章からどうぞ！
サインオン・ポリシー概要
簡単にサインオン・ポリシーの説明をさせていただきます。
すでにご存知の方は、こちらから次の章に飛んでくださいね！
サインオン・ポリシーとは
OCIコンソールや特定のアプリケーションへのログイン時に適用するルールを定義するものです。
アイデンティティ・ドメインにデフォルトで存在するサインオン・ポリシーは以下の3つです。
管理者が触ることが多いのは、OCIコンソールのログインに関わる②だと思います。
デフォルト・ドメインとカスタム・ドメインは挙動が違う？
| デフォルト・ドメイン | カスタム・ドメイン | |
|---|---|---|
| 作成タイミング | テナンシ有効化時に自動作成 | ユーザーが作成 |
| 管理者グループ | Administrators | Domain_Administrators |
Administratorsは2種類あり、今回お話しするのは、デフォルト・ドメインの方です。
結論から言うと、デフォルト・ドメインの管理者は、どのサインオン・ルールにも一致しなかった場合、ログインが許可されてしまいます。
これはOCIの仕様で「break-glass（緊急アクセス）」と呼ばれ、誤ったポリシー設定によって管理者自身がロックアウトされるのを防ぐためのものです。
なぜAdministratorsだけ？
「ブレーク・ガラス・ワークフロー」の仕組み
OCIはデフォルト・ドメインに対して、ブレーク・ガラス・ワークフローを自動で作成しています。
このワークフローは、以下のすべての条件を満たしている場合に適用されます。
- ユーザーがAdministratorsグループのメンバーである
- デフォルト・ドメインにログインしようとしている
- サインオン・ポリシーに明示的な拒否ルールが設定されていない
下図は、社内ネットワークからのアクセスのみを許可するルールが設定された状態で、社外から Administrators1 と user1 がログインを試みた場合の評価フローです。
ここでは、両者ともサインオン・ルールの条件にマッチしない例で考えてみましょう。
どちらもルール1・ルール2のいずれにも一致しませんが、結果は異なります。
Administrators1 はデフォルト・ドメインのAdministratorsであり、かつ明示的な拒否ルールが存在しないため、break-glassが発動しログインが許可されます。
user1 はAdministratorsではないため break-glass の対象外となり、アクセスが拒否されます。
対処方法
対処法はもちろんあります。
拒否ルールを入れるか、そもそもAdministratorsグループには重要人物以外入れない等の方法です。
他にも良い方法があるかもしれません。ご参考までに。
【方法1】拒否ルールを追加する
こちらは、すでにAdministratorsにたくさんのユーザーがいて、変更が難しい場合などに有効です。
【方法2】のAdministratorsを使わない方針にする場合、受け皿となるグループや、ポリシーなどの設計を考えなければなりません。
ですが、この方法を使えば、これまでの運用は変わらずにAdministratorsを制御できます。
注意点として、誰か1人以上は必ず除外メンバーを入れてください。
理由は、万が一の事態にアクセスできるユーザーを残しておきたいからです。
除外するメンバーは、例えばテナンシ有効化を行ったようなマネージャー相当の人物か、メーリングリストなどで登録されたユーザーなどが好ましいでしょう。
本当の緊急時には、ネットワーク・ペリメータにより接続元IPにより制御されていたとしても、ルールから除外されたメンバーのみどこからでもログインが可能です。
その他のAdministratorsはネットワーク・ペリメータ外のIPからアクセスしてきた場合、ログインが拒否されます。
1.「サインオン・ルールの追加」＞ルール名「Deny All Access」などとつけます。
2.「ユーザーを除外」にて、重要なAdministratorsユーザーを選択します。
3.「アクション」の項目で「アクセスの拒否」を選択します。作成後、最後の優先度に追加されていればOKです。
この設定の場合、以下のようなフローになります。
デフォルト設定と異なるのは、ちゃんとAdministratorsユーザーも拒否ルールによって弾かれているという点です。
一部の除外ユーザーは拒否されないため、コンソールにアクセス可能です。
これによりすべてのユーザーがOCIコンソールから締め出されてしまうリスクも防げます。
【方法2】Administratorsは極力使わない
こちらの方法は、テナンシ構築の段階から運用方針として設計しておく場合に適した方法です。
すでに多くのAdministratorsユーザーがおり、設定変更の合意を取るのが難しい場合は【方法1】が良いかも知れません。
設定は簡単で、重要な人物のみをAdministratorsに設定し、それ以外のユーザーは作ったグループに所属させます。
こちらのメリットは、以下2点だと思っています。
①サインオン・ポリシーに複雑な設定を入れないため、管理が楽
②Administratorsは限られた人物のみにできる上、ブレーク・ガラス・ワークフローにより緊急アクセスも可能
【方法1】に比べて、設計意図や運用方針がわかりやすいですね。
1. デフォルト・ドメインにグループ「（例）admin-group」を作成します。
2. ポリシー「（例）admin-policy」を作成し、ステートメントはAdministratorsと同等の権限を設定します。
こちらの場合は、最初に示したフローと同様になります。
admin-groupを含むすべてのユーザーは社外アクセスを行った場合アクセスが拒否されます。
Administratorsは引き続き、ブレーク・ガラス・ワークフローによりアクセス可能です。
まとめ
デフォルト・ドメインのAdministratorsには、ユーザーの誤った設定によってOCIコンソールから締め出されてしまうことを防ぐために、このような仕様があったんですね。
Administratorsグループは、テナンシ全体へのフル・アクセス権を付与します。このため、テナンシの日常管理に管理者アカウントを使用しないことがベスト・プラクティスです。
参照: セキュリティ
ドキュメントにも記載がある通り、基本的に使用しないでねと書かれてありますし、できることなら【方法2】で行くべきでしょう。
ですが、今回のように【方法1】により、Administratorsであってもアクセスを拒否することも可能です。
最後までお読みいただき、ありがとうございました！この記事が皆様の設計・運用の参考になれば幸いです。