Javaでの動的コード評価-賢いのか、ずさんなのか？

アプリケーション用にJavaで柔軟なACLフレームワークを作成しようとしています。

多くのACLフレームワークはルールのホワイトリストに基づいて構築されています。ルールはowner：action：resourceの形式です。例えば、

• 「ジョンはリソースFOOBAR-1を表示できます」
• 「MARYはリソースFOOBAR-1を表示できます」
• 「MARYはリソースFOOBAR-1を編集できます」

これは、ルールをデータベースに簡単にシリアル化/永続化できるため魅力的です。しかし、私のアプリケーションには複雑なビジネスロジックがあります。例えば、

• 「5年以上の年功歴を持つ部門1のすべてのユーザーは、リソースFOOBAR-1を表示できます。それ以外の場合は承認されません」
• 「部門2のすべてのユーザーは、日付が2016年3月15日以降であれば、リソースFOOBAR-2を表示できます。それ以外の場合は許可されません」

最初に考えたとき、このような無限に複雑なルールを処理できるデータベーススキーマを考案するのは悪夢です。したがって、コンパイルされたアプリケーションにそれらを「焼き付け」、ユーザーごとに評価し、評価の結果としてowner：action：resourceルールを生成する必要があるように思えます。 コンパイルされたアプリケーションにロジックを焼き付けないようにします。

そのため、私はルールを述語：action：resourceの形式で表現することを考えていました。ここで、述語はユーザーが許可されるかどうかを決定するブール式です。述語は、JavaのRhinoエンジンで評価できるJavaScript式の文字列になります。例えば、

• return user.getDept() == 1 && user.seniority > 5;

そうすることで、述部をデータベースに簡単に永続化できます。

これは賢いですか？これはずさんですか？これはギミックですか？これは過剰に設計されていますか？これは安全ですか（明らかに、JavaはRhinoエンジンをサンドボックス化できます）。

動的言語を実装言語のインタープリターにパイピングすることは、データ破損の可能性を悪意のあるアプリケーションの乗っ取りの可能性に拡大するため、通常は悪い考えです。言い換えれば、あなたがするあなたの方法で外出している作成するコードインジェクションの脆弱性を。

問題は、ルールエンジンまたはドメイン固有言語（DSL）によってよりよく解決できます。これらの概念を調べて、車輪を再発明する必要はありません。

私はこれを行いましたが、しないことをお勧めします。

私がやったのは、すべてのビジネスロジックをLuaで記述し、そのLuaスクリプトをデータベースに保存することでした。アプリケーションが起動すると、スクリプトが読み込まれて実行されます。そうすれば、新しいバイナリを配布せずにアプリケーションのビジネスロジックを更新できます。

変更を加えるときは常にバイナリを更新する必要があることを常に見つけました。Luaスクリプトにはいくつかの変更がありましたが、必ず変更のリストが必要だったため、ほとんど常にバイナリの変更とLuaスクリプトの変更が必要になりました。常にバイナリを配布することを避けることができるという私の想像は、単にうまくいきませんでした。

はるかに役立つとわかったのは、バイナリの配布を容易にすることでした。私のアプリケーションは、起動時にアップデートを自動的にチェックし、アップデートをダウンロードしてインストールします。したがって、ユーザーは常にプッシュした最新のバイナリを使用しています。バイナリの変更とスクリプトの変更にほとんど違いはありません。もう一度やったら、アップデートをシームレスにするためにさらに努力しました。

データベースにコードが含まれていません。ただし、データベースに関数名を含め、リフレクションを使用してそれらを呼び出すことで、同様のことができます。新しい条件を追加するときは、コードとデータベースに追加する必要がありますが、それらに渡される条件とパラメーターを組み合わせて、非常に複雑な評価を作成できます。

言い換えれば、部門に番号を付けている場合、UserDepartmentIsチェックとTodayIsAfterチェックを簡単に作成し、それらを組み合わせてDepartment = 2およびToday> 03/15/2016にすることができます。許可の日付を終了できるようにTodayIsBeforeチェックが必要な場合は、TodayIsBefore関数を作成する必要があります。

ユーザーのアクセス許可についてはこれを行っていませんが、データ検証については行っていますが、動作するはずです。

XACMLは、本当に探しているソリューションです。これは、アクセス制御のみに焦点を合わせたルールエンジンの一種です。OASISによって定義された標準であるXACMLは、3つの部分を定義しています。

• 建築
• ポリシー言語（実際に必要なもの）
• 要求/応答スキーム（承認決定の依頼方法）。

アーキテクチャは次のとおりです。

• ポリシー決定ポイント（PDP）は、アーキテクチャの中核部分です。既知の一連のポリシーに対して着信許可要求を評価するコンポーネントです
• Policy Enforcement Point（PEP）は、アプリケーション/ API /サービスを保護するコードです。PEPはビジネスリクエストをインターセプトし、XACML承認リクエストを作成し、PDPに送信し、応答を受信し、応答内で決定を実施します。
• ポリシー情報ポイント（PIP）は、PDPを外部のデータソース（LDAP、データベース、Webサービスなど）に接続できるコンポーネントです。PEPは、「アリスはドキュメント＃12を表示できますか？」などの要求をPEPが送信するときに役立ちます。PDPには、ユーザーの年齢を要求するポリシーがあります。PDPはPIPに「アリスの年齢を教えて」と尋ね、ポリシーを処理できるようになります。
• ポリシー管理ポイント（PAP）は、XACMLソリューション全体を管理する場所です（属性の定義、ポリシーの作成、PDPの構成）。

最初の使用例は次のとおりです。

/*
 * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
 * 
 */
 policy departmentOne{
    target clause department == 1
    apply firstApplicable
    /**
     * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
     */
    rule allowFooBar1{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }

 }

2番目のユースケースは次のとおりです。

 /*
  * "All users in department 2, if the date is after 03/15/2016, can VIEW resource FOOBAR-2, else not authorized"
  *  
  */
  policy departmentTwo{
    target clause department == 1
    apply firstApplicable
    rule allowFooBar2{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and currentDate>"2016/03/15":date and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }
  }

参照を使用して、両方のユースケースを単一のポリシーに結合できます。

  policyset global{
    apply firstApplicable
    departmentOne
    departmentTwo
  }

これで完了です！

XACMLおよびALFAの詳細については、次を参照してください。

• XACML 開発者のブログ
• XACML開発者のYouTubeチャンネル

ここで本当に必要なのはXACMLです。それはあなたが望むものをまさにあなたに与えます。必ずしもすべての役割を完全に分離した完全なアーキテクチャを実装する必要はありません...アプリケーションが1つだけの場合は、おそらくバラナを使用してPDPとPEPをアプリに統合することで逃げることができ、PIPは何でもかまいません既存のユーザーデータベースです。

これで、アプリのどこかで何かを承認する必要がある場合、ユーザー、アクション、およびコンテキストを含むXACMLリクエストを作成し、XACMLエンジンは、作成したXACMLポリシーファイルに基づいて決定を下します。これらのポリシーファイルは、データベースまたはファイルシステム、または構成を保持したい場所に保存できます。Axiomaticsには、生のXMLよりも読みやすいALFAと呼ばれるXACML XML表現の優れた代替手段と、ALFAポリシーからXACML XMLを生成するEclipseプラグインがあります。

現在の会社でこれを行いましたが、結果に非常に満足しています。

式はjsで記述されており、ユーザーがElasticSearchのクエリから取得できる結果を制限するためにも使用されます。

トリックは、決定を下すのに十分な情報を利用できるようにすることです。そのため、コードを変更せずに、必要なパーマを実際に記述しながら、同時に高速に保つことができます。

権限はシステムを攻撃する必要のない人によって作成されるため、コードインジェクション攻撃についてはあまり心配していません。そして、while(true)例のようなDOS攻撃にも同じことが当てはまります。システムの管理者はそれをする必要がありません、彼らはちょうどみんなの許可を削除することができます...

更新：

XACMLのようなものは、組織の中央認証管理ポイントとして優れているようです。私たちのユースケースは、クライアントが通常、すべてを実行するIT部門を持たないという点でわずかに異なります。自己完結型のものが必要でしたが、可能な限りの柔軟性を維持しようとしました。