コーダーがセキュリティインフラストラクチャを征服するコードシリーズ:欠けている機能レベルのアクセス制御

次回のInfrastructure as Codeシリーズの記事では、皆さんのような開発者が組織内に安全なインフラストラクチャを導入する際に、まったく新しいレベルのセキュリティ意識へと導きます。

ところで、前回のブログで取り上げたセキュリティ設定ミスの課題にどう対処しましたか？足りない機能レベルのアクセス制御の脆弱性に今すぐ取り組みたいなら、プラットフォームに進んでください。

（上記のリンクからKubernetesチャレンジに移動できますが、プラットフォームにアクセスしたら、ドロップダウンを使用してAnsible、CloudFormation、Terraform、Dockerから選択することもできます。選択はあなた次第です。)

現在導入されているほとんどすべてのアプリケーションには、要求された機能を実行する権限がユーザーに付与されているかどうかを確認する、何らかのアクセス制御メカニズムがあります。これは、アプリケーションを作成するときの機能性だけでなく、優れたセキュリティの基礎でもあります。実際、さまざまな権限を持つユーザーがプログラムを使用できるようにするには、すべての Web アプリケーションにアクセス制御が必要です。

ただし、アクセス制御の同じ検証機能がインフラストラクチャレベルで実行されなかったり、誤って構成されたりすると、問題が発生する可能性があります。インフラストラクチャーレベルのアクセス制御が完璧な順序でなければ、企業全体がハッカーにさらされ、ハッカーはその脆弱性を不正なスヌーピングや全面攻撃の入り口として利用する可能性があります。

実際、機能アクセス制御の脆弱性が見つからない、または誤って構成されている脆弱性を悪用することは非常に簡単です。攻撃者は過度に熟練している必要すらありません。必要なのは、そのアプリケーションをサポートしているフレームワークの中で、どのコマンドが関数を実行するのかを知ることだけです。もしそうなら、それは試行錯誤の問題です。許可されてはいけないリクエストを継続的に送信する可能性があり、成功するとすぐに、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開される可能性があります。

ミッシング・ファンクション・レベル・アクセス・コントロール・エクスプロイトの仕組み

機能レベルのアクセス制御が組織に浸透する方法はいくつかあります。たとえば、機能レベルのアクセスはアプリケーションに任せて、基盤となるインフラストラクチャでは検証されない場合があります。あるいは、インフラストラクチャーレベルのアクセス制御が誤って設定されている可能性もあります。管理者が、権限のないユーザーにはインフラストラクチャーのリソースへのアクセス方法がわからないと考え、上位レベルのユーザーだけが見ることができるはずの「セキュリティ・バイ・セキュリティー (Security by Obscurity)」モデルを使用することがありますが、これはほとんど機能しません。

あいまいさによるセキュリティの例として、次の URL は攻撃を受けやすい可能性があります。

http://companywebsite.com/app/NormalUserHomepage

認証されたユーザーが強制URLブラウズと呼ばれる手法を使用すると、管理者にのみ表示されるページにアクセスしようとする可能性があります。例としては、次のようなものが考えられます。

http://companywebsite.com/app/AdminPages

サーバー側での検証が行われていない場合は、管理ページが表示され (その名前がリクエストと一致する場合)、管理者が新しいページから行う追加機能にアクセスできるようになります。サーバーが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページに付けられた名前がわかるまで試行を続けることができます。

攻撃者の場合、悪用 機能レベルのアクセス制御がない 同様のプロセスです。権限のないページを閲覧しようとする代わりに、関数リクエストを送信します。たとえば、管理者権限を持つ新しいユーザーを作成しようとするかもしれません。そのため、フレームワークによっては次のようなリクエストになります。

投稿/アクション/ユーザー名作成=ハッカー&pw=パスワード&ロール=管理者

機能レベルのアクセス制御が存在しない場合、上記の例は成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者としてログインし直すと、そのネットワークまたはサーバー上の他の管理者と同じアクセス権と権限を持つことになります。

機能レベルのアクセス制御が欠けている場合の修正

機能レベルのアクセス制御に欠けている脆弱性は、攻撃者が簡単に悪用できるため、脆弱性を発見、修正、防止することが重要です。ありがたいことに、ある程度のノウハウと基本的なインフラストラクチャがあれば、これはそれほど難しくありません。 コードセキュリティトレーニング。

主な保護策は、インフラストラクチャレベルでロールベースの認証を実装することです。アプリケーションがその機能を処理することを決して信頼しないでください。たとえそうであっても、インフラストラクチャー側の承認があれば、見落としがないことが保証されます。認証は、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用される一元的な場所 (AWS IAM、Azure IAM など) から行うのが理想的です。これらの承認プロセスは、フレームワーク自体から行うことも、いくつもの使いやすい外部モジュールから行うこともできます。

最後に、組織は最小権限の概念を採用する必要があります。デフォルトではすべてのアクションと機能を拒否し、承認プロセスを使用して有効なユーザーに必要な操作を行う権限を与える必要があります。ユーザーには、必要な機能を実行するのに十分な権限のみを、必要な期間だけ付与する必要があります。

機能レベルのアクセス制御が欠けていると、壊滅的な打撃を受ける可能性があります。しかしありがたいことに、優れたインフラストラクチャレベルの認証方法を組織に組み込むことで、この問題の発生を簡単に防ぐことができます。

アクセス制御のバグを実際に発見する準備はできていると思いますか？次の Docker コードスニペットを比較してください。1 つは脆弱で、もう 1 つは安全です。

傷つきやすい:

quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザールート
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]

安全:

quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザーなし
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]

詳細を学び、自分自身に挑戦してください

をチェックしてください セキュア・コード・ウォリアー この脆弱性や、他のセキュリティ上の欠陥や脆弱性による被害から組織や顧客を保護する方法について、さらに詳しく知るためのブログページをご覧ください。

また、以前に見逃した場合でも、 IaC ゲーミフィケーションセキュリティチャレンジを試してみる Secure Code Warriorプラットフォームで、すべてのサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。

次章をお楽しみに！