Coders Conquer Security Infrastructure as Codeシリーズ：機能レベルのアクセス制御の欠如

Infrastructure as Codeシリーズの第2弾をお届けします。本ブログでは、開発者の皆さんが組織内でセキュアなインフラを構築する際に、セキュリティ意識を一段上のレベルへ引き上げるための知識を解説します。

ところで、前回のブログで紹介したセキュリティ設定不備のチャレンジには挑戦しましたか？もし今すぐ「機能レベルのアクセス制御の欠如」という脆弱性に挑んでみたい方は、以下のプラットフォームへアクセスしてください。

（上記のリンクはKubernetesのチャレンジへ繋がっていますが、プラットフォームにアクセス後、ドロップダウンメニューからAnsible、CloudFormation、Terraform、Dockerを選択することも可能です。お好きなものをお選びください。）

今日デプロイされるアプリケーションのほとんどには、ユーザーが要求した機能を実行する権限を持っているかどうかを確認するアクセス制御メカニズムが備わっています。これはアプリケーションを作成する上で、機能面だけでなくセキュリティ面においても極めて重要な基盤です。実際、あらゆるWebアプリケーションにおいて、権限の異なるユーザーがプログラムを利用できるようにするためには、アクセス制御が不可欠です。

しかし、こうしたアクセス制御の検証機能がインフラレベルで実行されていなかったり、設定が不適切だったりすると問題が発生します。インフラレベルのアクセス制御が適切に整備されていないと、企業全体がハッカーの標的となり、その脆弱性を悪用して不正な覗き見や本格的な攻撃を仕掛けられる恐れがあります。

実際、機能レベルのアクセス制御の欠如や設定不備を突く攻撃は非常に簡単です。攻撃者は高度なスキルを持っている必要さえありません。アプリケーションを支えるフレームワークにおいて、どのコマンドがどの機能を実行するかを知っていれば十分なのです。あとは試行錯誤を繰り返すだけです。許可されるべきではないリクエストを送り続け、一度でも成功すれば、標的となったWebサイト、アプリケーション、サーバー、あるいはネットワーク全体が危険にさらされることになります。

機能レベルのアクセス制御の欠如を突く攻撃の仕組みとは？

機能レベルのアクセス制御の不備が組織に紛れ込む原因はいくつかあります。例えば、アクセス制御をアプリケーション側に任せきりにして、基盤となるインフラ側で検証を行っていないケースや、インフラレベルのアクセス制御の設定が誤っているケースなどです。また、管理者権限を持つユーザーしかアクセスできないリソースには、権限のないユーザーはたどり着けないだろうと思い込んでいるケースもあります。これは「隠蔽によるセキュリティ（Security by Obscurity）」と呼ばれるモデルですが、ほとんどの場合、効果はありません。

「隠蔽によるセキュリティ」の例として、以下のURLは攻撃に対して脆弱である可能性が高いと言えます。

http://companywebsite.com/app/NormalUserHomepage

認証済みのユーザーが「強制URLブラウジング（Forced URL Browsing）」という手法を用いると、管理者のみに表示されるページにアクセスしようと試みることができます。例を挙げると以下の通りです。

http://companywebsite.com/app/AdminPages

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

攻撃者にとって、機能レベルのアクセス制御の欠如を悪用するプロセスも同様です。許可されていないページをブラウジングしようとする代わりに、機能のリクエストを直接送信します。例えば、管理者権限を持つ新しいユーザーを作成しようとする場合、フレームワークにもよりますが、リクエストは以下のようになります。

POST/action/createuser name=hacker&pw=password&role=admin

もし機能レベルのアクセス制御が存在しなければ、上記のリクエストは成功し、新しい管理者アカウントが作成されてしまいます。攻撃者がその新しい管理者としてログインすれば、そのネットワークやサーバー上の他の管理者と同じアクセス権限を手に入れることになります。

機能レベルのアクセス制御の欠如に対する修正策

機能レベルのアクセス制御の欠如という脆弱性は、攻撃者にとって悪用が非常に容易であるため、発見、修正、そして未然に防ぐことが極めて重要です。幸いなことに、適切な知識と基本的なInfrastructure as Code（IaC）のセキュリティトレーニングがあれば、それほど難しいことではありません。

主な保護策は、インフラストラクチャレベルでロールベースの認可を実装することです。この機能をアプリケーション側に依存してはいけません。仮にアプリケーション側で実装していたとしても、インフラ側で認可を行うことで、漏れを確実に防ぐことができます。理想的には、組織のルーチンに組み込まれ、すべての新規アプリケーションに適用される一元化された場所（AWS IAM、Azure IAMなど）から認可を行うべきです。これらの認可プロセスは、フレームワーク自体から提供されるものや、使いやすい外部モジュールを多数活用できます。

最後に、組織として「最小権限の原則」を採用してください。すべての操作と機能はデフォルトで拒否されるべきであり、認可プロセスを通じて、正当なユーザーに必要な権限のみを付与するようにします。権限は、必要な機能を実行するために必要な範囲で、かつ必要な期間のみ与えるべきです。

機能レベルのアクセス制御の欠如は、壊滅的な被害をもたらす可能性があります。しかし幸いなことに、組織内に優れたインフラレベルの認可慣行を構築することで、このような問題を未然に防ぐことは容易です。

実際の環境でアクセス制御のバグを見つける準備はできましたか？以下のDockerコードスニペットを比較してみてください。一方は脆弱で、もう一方は安全です。

脆弱なコード:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=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 $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

安全なコード:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=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 $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

さらに学び、挑戦する

この脆弱性に関する詳細や、他のセキュリティ上の欠陥から組織と顧客を守る方法については、Secure Code Warriorのブログをご覧ください。

また、先ほど紹介したIaCのゲーミフィケーション形式のセキュリティチャレンジをSecure Code Warriorプラットフォームで試して、サイバーセキュリティのスキルを常に磨き、最新の状態に保ちましょう。

次回の章もお楽しみに！