Coders Conquer Security Infrastructure as Codeシリーズ - ビジネスロジック

さて、今回のシリーズは（一旦）ここまでとなります。「Infrastructure as Code」シリーズはこれにて完結です。Docker、Ansible、Kubernetes、Terraform、CloudFormationにおけるセキュリティ課題の克服を楽しんでいただけたなら幸いです。最後に、習得すべき脆弱性がもう一つ残っています。それは「ビジネスロジックのバグ」です。

スキルを試す準備はできましたか？最後のゲーミフィケーション・チャレンジに挑戦してみましょう。

まだ不明な点がある場合は、以下を読み進めてください。

今回焦点を当てる脆弱性は、ビジネスロジックの欠陥です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生する可能性があり、悪意のあるユーザーに悪用された場合、アプリケーションがさまざまな攻撃に対して脆弱になる恐れがあります。アプリケーションに実装された目的や機能によっては、ビジネスロジックの欠陥により、権限昇格や不適切なリソース使用、あるいは意図しないビジネスプロセスの実行などが引き起こされる可能性があります。

多くの脆弱性とは異なり、ビジネスロジックのルールの実装ミスは非常に巧妙な場合があります。アプリケーションやコードに紛れ込ませないよう、特別な警戒が必要です。

ビジネスロジックの欠陥にはどのような例があるのでしょうか？

ビジネスロジックの欠陥がいかに簡単に発生し得るかを示す例として、Docker Composeファイルで定義されたDocker環境の以下の例を見てみましょう。コンテナが機能を実行できるように準備する際、開発者はDocker Composeファイルで定義された標準的なリソースポリシーを使用することがあります。

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"

一見問題ないように見えますが、このコンテナのリソースポリシーではリソース使用量が適切に制限されていません。攻撃者はこのビジネスロジックの欠陥を悪用して、サービス拒否（DoS）攻撃を仕掛ける可能性があります。

ユーザーによるリソースの過剰な消費を制限しようと、開発者は各コンテナがサポートできる内容をより詳細に定義しようとするかもしれません。そこで、新しいコードに配置制約（placement constraint）を追加してみます。

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"
   placement:
     constraints:
       - "node.labels.limit_cpu == 100M"
       - "node.labels.limit_memory == 0.5"

一見すると、これでビジネスロジックの欠陥が解決されたように見えます。しかし、この新しい配置制約は、Dockerコンテナサービスのリソース使用制限には影響しません。これはコンテナをスケジュールするノードを選択するためにのみ使用されます。この場合でもDoS攻撃は依然として可能です。攻撃者はまずDockerコンテナに侵入する必要がありますが、侵入後は制限なしにリソースを枯渇させることができてしまいます。

このように、ビジネスロジックの欠陥について考え、それを排除するようにプログラミングすることは、難しい取り組みとなり得ます。

ビジネスロジックの欠陥を排除する

ビジネスロジックの欠陥において重要なのは、その存在を認識することです。新しいコードを書く際には、環境内に欠陥が入り込まないよう常に警戒する必要があります。ビジネスルールとベストプラクティスを明確に定義し、設計、実装、テストを含むアプリケーション開発プロセスのすべての段階でチェックを行うべきです。

例えば、上記の例のようなDoS攻撃を可能にするビジネスロジックの欠陥を防ぐには、作成するすべてのDockerコンテナが使用できるリソース量を制限するのがベストプラクティスです。具体的には、limitsセクションでDockerコンテナが使用できるCPU数とメモリ量を指定する必要があります。例を挙げます。

deploy:
 resources:
   limits:
     cpus: "0.5"
     memory: 100M
   reservations:
     cpus: "0.5"
     memory: 50M

上記のようなコードをポリシーとして使用すれば、環境から重大なビジネスロジックの欠陥を取り除き、DoS攻撃を防ぐことができます。これは、攻撃者がDockerコンテナのいずれかに侵入した場合でも有効です。その場合でも、攻撃者は足がかりを利用してリソースを枯渇させることはできません。

脅威モデリングは、さまざまな攻撃がどのように発生するかを定義し、ビジネスロジックルールを用いてそれらを防止・制限する上で役立ちます。コンプライアンスルールや既知の悪用事例に基づいたテストを行うことも、見落とされがちなビジネスロジックの欠陥を特定するのに有効です。

ビジネスロジックの欠陥は、アプリケーションに紛れ込む脆弱性の中でも特に巧妙なものですが、他の注目度の高いリスクと同様に危険です。発生の仕組みを理解し、ベストプラクティスを実践することで、開発段階でこれらを排除できます。これにより、悪用方法を熟知した攻撃者に狙われる本番環境への流出を確実に防ぐことができます。

この脆弱性に関する詳細や、その他のセキュリティ上の欠陥から組織と顧客を守る方法については、Secure Code Warriorのブログページをご覧ください。また、Secure Code WarriorのトレーニングプラットフォームでこのIaCチャレンジのデモを試すことで、サイバーセキュリティスキルを常に最新の状態に保つことができます。