ビジネス効率は最大限のAI支援の使用を要求していますが、ポリシー・アズ・コードに関しては、AIは深刻なポリシー欠陥を導入する可能性があります。
組織のセキュリティ、コンプライアンス、および運用ルールのためのポリシー・アズ・コード化へのシフトに続いて、生コードの生成を支援するためのLLM人工知能の使用が増加しています。これは理にかなっています。ビジネス内のAIの主な目的は人間の効率を改善することであり、RegoやCedarなどの言語でポリシーを記述することは簡単ではありません。AIはますますこのプロセスを効率化するために使用されています。
しかし、問題があります。これらの生成されたポリシーはしばしば正しく見え、正常にコンパイルされ、それでも間違ったアクセスを許可します。これは完全に驚くべきことではありません。AI生成アプリケーションは、最も安全なソリューションよりも最も単純なソリューションを選択することによってセキュリティ問題を導入する可能性があることがすでに知られています。しかし、セキュリティ問題を防ぐために設計された組織的なポリシー内のセキュリティ問題は、特に問題があります。
独立系研究者（およびAppleのシニアセキュリティエンジニア）であるVatsal Guptaは、これらの問題を調査し、SecurityWeekと議論しています。「LLMはエンジニアリングワークフローに導入されています。開発者はそれらを使用してインフラストラクチャコード、セキュリティルール、そして現在はアクセス制御ポリシーを生成しています」と彼は述べています。
その魅力は明らかです。「ポリシーロジックを手動で記述する代わりに、チームはプレーンな言語で意図を記述し、モデルに実行ロジックを生成させることができます。」
しかし、それはいつもそのように機能するわけではありません。「LLM生成ポリシーは構文的には有効なことが多いですが、意味的には正確ではありません」とVatsalは続けます。「1つの欠落した条件、誤釈された属性、または不正なアクションは、誰が何にアクセスできるかを完全に再定義する可能性があります。」
これらは明らかな失敗ではありません。ビルドを壊したり、アラートをトリガーしたりはしません。しかし、それらはアクセス境界を静かに拡張します。そしてVatsalの研究は様々な繰り返される失敗パターンを発見しました。
彼が私たちに述べるところによると、一般的な問題は文脈的制約の欠落です。「地域、部門、または所有権に基づいてアクセスを制限することになっているポリシーは、その条件を完全に省略する可能性があります。生成されたポリシーはまだ整然としており有効に見えますが、今では意図されたスコープ内ではなく、グローバルに適用されます。」
2番目は、彼が続けるところによると、拒否ロジックの欠落です。「多くのアクセス制御ポリシーは、特定の例外を伴うベースラインの拒否姿勢に依存しています。LLMはしばしば例外をキャプチャしますが、基礎となる制限をエンコードすることに失敗します。結果は、要件を実装しているように見えますが、意図したものより多くを許可するポリシーです。」
その後、LLMの標準的な繰り返しの問題があります—幻覚を起こす可能性です。「モデルは時々、実際のシステムスキーマに存在しない属性を導入します。ポリシーはコンパイルされますが、実行時には、存在しないか誤ってマップされたデータに依存するため、予測不可能に動作します。」
時間的および文脈的条件はしばしば削除されます。「時間ウィンドウ、承認、またはセッションコンテキストに依存するポリシーは、静的ルールに簡略化されます。制御されることが意図されていた、時間制限付きアクセスは常時有効なアクセスになります。」
そして最後の懸念：「アクション誤分類さえ発生する可能性があります。削除などの機密アクションを制限することを目的としたポリシーは、より広い、または異なるオペレーションに翻訳される可能性があります。差異は言葉では小さいかもしれませんが、影響では大きい可能性があります。」
これらすべての失敗は、AIの言語を解釈および簡略化する意図からの自然な結果です。結果は、見た目が良く、感じが良く、味が良いが、単に良くないポリシーになる可能性があります。そして、良くないことの検出は困難です。
時間とともに、これらの小さな偏差が蓄積します。ポリシーはもはや時々レビューされる静的アーティファクトではなく、継続的に生成、更新、および展開されます。「より多くのポリシーが生成、展開、および再利用されるにつれて、リスクは複合します」とVatsalは続けます。組織は最小権限を実施していると信じているかもしれませんが、実際には過度にアクセス許可された環境に向かって漂流しています。
「生成プロセスが信頼できない場合、リスクはシステミックになります」と彼は付け加えます。「組織は微妙に欠陥のある数千のポリシーを持つことになるかもしれません。各欠陥は個別には小さいかもしれませんが、全体的には大きく理解しにくい攻撃面を作成します。」
彼は、解決策はLLMを放棄することではなく、特にポリシーに関して、私たちの信頼モデルを変更することだと述べています。「生成されたポリシーはデフォルトで正しいものとして扱われるべきではありません。生成と実行の間に検証レイヤーを導入して、必要なすべてのコンポーネントが存在し、正しく、期待される動作と一致していることを確保する必要があります。ポリシーはテストされるべきで、単にコンパイルされるべきではありません。そして、デフォルトで拒否する原則は明示的に実施されるべきです。」
最も重要なことに、彼は「組織は認可ロジックを高リスク領域として扱う必要があります」と付け加えています。モデルがコードを生成できるからといって、そのコードが精査なしで安全に展開できるわけではありません。
「AI支援セキュリティエンジニアリングに向かう際、目標は単に自動化であるべきではありません。それは正確さ、監査可能性、および信頼であるべきです。認可においては、『ほぼ正しい』では十分ではないからです」とVatsalはSecurityWeekに語りました。
