はじめに
今回は2023年4月に発生したAzureのセキュリティ事案についてMSサポートとのやり取りも含めて共有・考察します。
事の発端
2023年4月11日、Orca Security社がストレージアカウントのアクセスキーを利用したAzureインフラの問題についてレポートしました。
その内容は下記サイトにも掲載され、これをきっかけに問題が波及しました。
問題の内容についてざっくり書くと
- Functionsを構成する際に作成されるストレージアカウントに対してフル権限を持っている場合、ストレージアカウントに悪意のあるコードを登録してFunctionsから実行できてしまう恐れがある
- 対象のFunctionsに割り当てられているマネージドIDのアクセストークンを盗み、特権に昇格することで、横方向の攻撃、仮想マシンでのリモート コードの実行できてしまう
というものです。これだけでは何をやっているかイマイチ分かりませんが、Azureエンジニアとして、この問題が顧客環境対してどのような影響があるのかを調査する必要がありました。
Microsoft社の見解
MicrsoftのMSRC（Microsoft Security Response Center）は、Orca Security社からの連絡を受け、以下のブログを更新しました。
記事には「これは脆弱性ではなく設計上の欠陥」との説明がありました。つまり、この問題は全てのAzure環境に対して悪意のある攻撃ができてしまう訳ではなく、「最小権限の原則」やMFAなど、いわゆる多層防御が出来ていれば容易に防ぐことができる問題だということが分かりました。
とはいえ、問題となっているFunctionsのストレージについては、Functionsとのやり取りをアクセスキーではなくマネージドIDをデフォルトとする方針で改修が進められています。リリース時期は現時点では未定ですが、２～３ヶ月後とのことです。（MSサポート回答より）
今回の問題の深堀
もう少し深掘ってみます。
Functionsを作成する際には、確かにストレージアカウントが必要になります。このストレージアカウントにはFunciotnsを構成するメタ情報が入っています。このストレージアカウントですが、Funcionsと連携する必要があるため、ストレージアカウントが持つFirewall機能は使えません。つまりデフォルトではアクセスキーが分かればフルアクセス出来てしまいます。
だた、フルアクセス出来てしまったとしても、通常はこのストレージアカウントにFunctionsのソースコードは入っていません。（隠ぺい化されています。）ただし、Functionsへのデプロイ方法の1つとして、実際のソースコードをこのストレージアカウントにアップロードするパタンがあります。この方法においては、フルアクセスできるユーザが悪意のあるコードに書き直して再アップすることで、悪用することができてしまいます。
さらに、FunctionsにマネージドIDが付与されている場合、このFunctionsの実行によりAzureリソースに何らか操作を加えることができます。そして、FunctionsのマネージドIDのトークンを盗み取ることでAzure環境全体を乗っ取ることができてしまうようです。
細かいメカニズムは不明ですが、FunctionsおよびFunctionsのストレージアカウントについて一定の（悪い方の）条件が揃うと今回の攻撃を受ける対象になりかねないということが分かりました。
どのような対策が打てるか
ここからは、本問題に対してどのような対策を打てば回避できるかについて考えてみます。
Functions作成時の注意点
まず、Functionsを使う際には、このストレージアカウントの取り扱いには十分注意することです。これはFunctionsを使う方は必ず意識しておきましょう。MSサイトにはこの件に特化して解説しているページもあります。このページに記載されている考慮事項をしっかり守りましょう。
更新権限は必要最小限に
RBACの世界では、更新アカウントと参照アカウントがあります。「最小権限の原則」に基づきこの2種類のアカウントを正しく使い分けるようにしましょう。通常は一般ユーザには参照権限しか持たない「閲覧者」ロールを払い出し、更新アカウントについてはPIMを用いた特権管理を行います。
今回の問題に照らし合わせると、「閲覧者」ロールでは、まずストレージアカウントの中が参照できません。参照に必要なアクセスキーの取得ができないためです。（アクセスキーの取得には Microsoft.Storage/storageAccounts/listKeys/action というロールが必要ですが、「閲覧者」はRead権限しか持っていません。）
また、Functionsの「アプリケーション設定」にはストレージアカウントのアクセスキーを含む接続文字列が AzureWebJobStorage という環境変数に入っていますが、こちらも「閲覧者」ロールでは参照不可です。
上のキャプチャではAzureWebJobStorageが見えていますが、「閲覧者」では非表示のままとなります。これだけでも「最小権限の原則」の有効性がわかっていただけると思います。
マネージドIDに対する権限付与にも注意
FunctionsのマネージドIDが持つ権限スコープも注意する必要があります。AzureリソースにマネージドIDを作成した場合にAzureロールを設定することになりますが、ここでも「サブスクリプションスコープ」や「共同作成者」権限といった強権限は避けた方がよいです。こちらも「最小権限の原則」に従い、権限範囲とスコープをできるだけ狭めるように意識しましょう。
※以前はデフォルトで「サブスクリプション」スコープ、「共同作成者」権限が付与された記憶がありますが、このあたり機能が変わってようで、デフォルトでは権限は設定されなくなっていました。
アカウントのMFA設定は必須
更新アカウントが万が一盗まれてしまった場合でも、MFAを有効化しておけば大抵のトラブルは回避できます。過去の調査ではMFAを付けることで90%以上のインシデントを回避することができる、といったレポートもあります。MFAを有効化するには「条件付きアクセス」か「セキュリティデフォルト」を有効にします。
「条件付きアクセス」はきめ細かなアクセス制御を設定することができますが、AzureADのP1ライセンス（PerUser）が必要です。他方「セキュリティデフォルト」は無償でありながら全てのアカウントのMFAを強制してくれるため、手っ取り早く導入するなら「セキュリティデフォルト」がよいでしょう。
アクセスキーや接続文字列を極力使わずマネージドIDやAzureAD認証を使う
ストレージアカウントにアクセスする際にアクセスキーを使うのは、2018年頃のマネージドIDが出てくるまではデフォルトの方法でした。ただ、当初からこの方法は危険性を秘めていて、ストレージアカウントのファイアフォールの有効化で防御していたものです。この点についてはここ数年でだいぶアップデートが入り、今ではマネージドIDやAzureAD認証といった機能でアクセスさせるのがベストプラクティスです。ぱっと見はアクセスキーの方が楽なのですが、セキュリティを考慮した場合の効果は計り知れませんので、多少面倒でも、マネージドIDやAzureAD認証をベースとした設計・運用されることをお勧めします。
おわりに
今回は、2023年4月11日に出されたOrca Security社のAzureセキュリティに関するレポートについて触れ、その内容を対策方法について解説しました。対策方法については、本件に限らずAzureにおいてごく一般的な方法になりますが、それだけ重要な事項ですので、対策取られてない方はすぐに対応するようお願いいたします。
ではまた。