ポリシーは簡単
この記事は https://docs.evolveum.com/iam/myths/policies-are-easy/ の翻訳です。
Cybersecurity には subject-action-object という trinity があります。 Triplet を組み合わせればポリシーになります。 これはファイアウォール、アクセス制御リストなど、あらゆる場所で使われています。 もちろん、少し複雑になることもあります。その場合は triplet に constraint を追加すれば完了です。 簡単です。
ポリシー言語
確かに、ポリシー language が複雑ではないというのは、理論上は部分的に true です。 もちろん triplet version、つまり subject-action-object は明らかにかなり素朴なです。 Constraint と組み合わせると、その言語は突然かなり強い expressive power を持ちます。 Firewall やそのような単純低レベル stuff には理想的です。 LDAP サーバーでさえ、アクセス制御リスト (ACL) で表現されたポリシーから効果を得られます。
しかし、少しでも複雑なことをしようとすると trouble に入ります。
これを試してみましょう。「ユーザー A からユーザー B への権限 P の delegation を許可する」。
これは (subject:A, 対応:delegation, オブジェクト:B, constraint:(権限=P)) とモデル化できます。
ここでの trick は、すべての複雑性を constraint 部分に隠すことです。
その部分は少し confusing になりますが、全体的なモデルは少なくとも単純ケースではまだ機能します。
ではケースを少し変えましょう。「Group C の member が、ユーザー A からユーザー B へ権限 P を delegation することを許可する」。
同じ trick を再び使えます。(subject:Group C, 対応:delegation, オブジェクト:A, constraint:(権限=P と target=B))。
または逆に (subject:Group C, 対応:delegation, オブジェクト:B, constraint:(権限=P と donor=A)) かもしれません。
かなり confusing で ambiguous になってきました。
もう1つ試しましょう。ログイン済みユーザーがユーザー A から B へ 委任できるすべての権限を 一覧表示する。
実現可能ですが、まだ簡単でしょうか。
アクセス制御 エンジニアing と research が何十年も行われてきたにもかかわらず、標準化された汎用ポリシー言語がまだ存在しないのには理由があります。 いくつかの standardization attempt は失敗するか、的外れに終わりました。 ディレクトリサーバーやデータベースのような比較的単純なシステムでさえ、一般的アクセス制御ポリシー言語について合意できていません。
実践的な問題
十分な表現力を持ち、あらゆるポリシーを表現できる、曖昧さのない理解可能なポリシー言語があると大胆に仮定しましょう。
では real 業務に入り、ポリシーを書き下しましょう。
どこから始めればよいでしょうか。
"Do not boil the ocean" と言われます。したがって単純なものから始めましょう。
Active Directory (AD) アカウントのポリシーを書きます。
誰が AD アカウントを持つべきかを指定するポリシーを書き、そのポリシーに合わないすべてのアカウントを削除します。
ポリシーは非常に単純です。「従業員 だけが AD アカウントを持つべきである」。
正確には、そうではありません。
Alice がいます。彼女は従業員ではありませんが、research プロジェクトで働いており、私たちのファイルにアクセスする必要があります。
これをポリシーでどう describe すればよいでしょうか。
ポリシーにユーザー名として alice を hard-code すべきでしょうか。
おそらく良い考え方ではありません。
ポリシーに "プロジェクト" の概念を導入すべきでしょうか。
どのプロジェクトが AD へのアクセスを付与すべきで、どれがそうでないかをどう区別するのでしょうか。
すでに物事は複雑になっています。
そして Bob がいます。彼は請負業者であり、私たちは PC 維持管理を彼に outsource しています。
彼も AD アクセスを必要とし、一部の管理権限も必要です。
これをポリシーでどう specify すればよいでしょうか。
現時点で、すべての請負業者と業務パートナーを、すべての 関係 とともにモデル化したいわけではありません。
私たちはまだ ocean を boil していません。
ポリシーに PC Administrator ロールを導入すべきでしょうか。
それは機能するかもしれません。
しかしそれは RBAC のように見え始めます。
ああ、ちょっと待ってください。
AD の administrator アカウントはどうすればよいのでしょうか。
そのようなアカウントの存在を許可するポリシー文はありません。
削除すべきでしょうか。
そのような high-risk アカウントを削除すれば、システムは確かに attack されにくくなるでしょう。
すべてが変化する
すべては変わります。ポリシーも同じです。 組織内のすべてのアクセス制御ポリシーを 機械処理可能な形で説明したファイルを想像してください。 それは小さなファイルにはならず、その内容はかなり複雑になるでしょう。 何千、何万行にもなります。 ここで recent ポリシー変更を反映するためにファイルを更新しなければなりません。 ファイルの正しい場所をどうやって見つけるのでしょうか。 ポリシーがまだ機能することをどう確信できますか。 ほとんどのユーザーを ロックアウト する誤りをしていないでしょうか。 更新の結果、すべての Active Directory アカウントが突然削除されることはありませんか。 もしかすると不注意にシステムを attack に開いているかもしれません。 Line が多すぎ、文が多すぎます。 どうやって確信できるのでしょうか。
これはソフトウェア開発者が毎日直面している問題です。 ソリューションがあります。堅牢な開発ツールチェーン、コンパイラー、開発環境、ビルドツール、テストフレームワーク、バージョン管理システムです。 ポリシーを維持するには、同じツールと方法、そして同じ skill が必要です。 その skill は簡単に身につくものではありません。
ここで、単純ファイアウォールポリシーを更新するのにどれだけ時間がかかるかを思い出してください。 Organization-wide ポリシーの更新は桁違いに難しくなります。 ユーザーは新しいアクセス権限をすばやく得ることに慣れています。 通常のアクセス申請と承認プロセスは、完了までに数分から数時間しかかかりません。 ポリシーへの変更をどれほど速く反映できますか。 ポリシーが分析、更新、ビルド、ステージング、検証、導入されるまで、ユーザーは数週間または数か月待つことに満足するでしょうか。
私たちが知っていること、知らないこと
ここまででも十分に面倒に見えます。 残念ながら、ポリシーベースの方法にはもう1つ重要な問題があります。 大きな問題はこうです。
ポリシーを specify したいなら、ポリシーが何であるかを 知っている 必要があります。
それは本当に問題でしょうか。 誰もがポリシーが何であるかを知っているはずです。 すべてのユーザーはユーザー agreement に署名し、会社ガイドラインを知っており、適用されるすべての規制について詳細な知識を持ち、これまでに行われたすべての管理判断を認識しています。 そうでなければ、どうやって日々の仕事をできるのでしょうか。
私たちは皆、自国に適用されるすべての legislation を知っているはずです。 本当に知っているでしょうか。 もちろん知りません。そうでなければ lawyer は不要です。 少なくとも legislation は clear で unambiguous ですよね。 もちろん違います。 法律を機械処理可能な形式に成文化しようとするすべての試みはひどく失敗します。 Lawyer を machine で置き換えることはできません。 これはかなり強い職務セキュリティです。
組織上のポリシーの状況も似ています。ただし1つ serious complication があります。 Legislation は通常書き下されていますが、会社ポリシーはそうではありません。 会社ポリシーの大きな部分は、常識、通常の慣行、subjective 考慮、そして会議議事録にすら記録されない管理判断に基づいています。
今、私たちはポリシーを exact, 完全, 理解可能, 最新, 保守可能 と machine-executable な形式で得ようとしています。 それはどれほど realistic でしょうか。
それでも簡単でしょうか。
解決への道
現実的には、完全ポリシーが すぐに使える形式で存在することを期待できません。 ポリシーの知識は組織内の多くの人に分散しています。 誰もが少しずつ知っており、その大半はポリシーに従って行動しています。 全体として、彼らはポリシーの "集合知" を持っています。 私たちはそれを利用できます。
1つの方法は、外に出てこれらすべての人に尋ねることです。 彼らは断片を教えてくれます。私たちはそれを分析し、組み合わせ、コード化し、洗練します。そしてポリシーができあがります。 それには 何年 もの hard 作業がかかりますが、確かに労力に値します。 ようやく完了したら、私たちは成功を祝えます。結果を捨てることによって。 その頃にはポリシーがその間に変更しているため、結果は役に立たなくなっているでしょう。 これは良い方法ではありません。 もっと速く、もっと smart なものが必要です。
私たちには既存データがあり、情報を マイニング できます。 これまでずっと group と ロール を使って権限を管理してきた可能性は高いです。 扱いにくいが機能している RBAC システムがすでにあるかもしれません。 Current グループメンバーシップとロール割り当てデータがあります。 組織が適切に機能している限り、ロールの大半はポリシーに従って割り当てられたと安全に仮定できます。 この情報を使ってポリシーを マイニング し、ポリシーが実際には何であるかを 判断できます。 もちろん、これは approximate 手法にすぎません。 現在のアクセスはおそらく過剰プロビジョニングであり、ポリシーは完全に一貫した形で適用されていない、などの問題があります。 しかし mining は、出発点として実践的な approximation を与えてくれます。 マイニングされたポリシーは段階的に洗練、見直し、最適化できます。 正確だが 実行困難 な方法に頼るより、実践的な approximate 方法を持つ方が優れています。 Done は perfect より良いのです。