Codeers Conquer Security Infrastructure as Codeシリーズ - ビジネスロジック
さて、これで（今のところ）終わりです。Infrastructure as Codeシリーズは今回で終了となります。Docker、Ansible、Kubernetes、Terraform、CloudFormationなどのセキュリティ問題を楽しく攻略していただけたでしょうか。
これで自分のスキルを試す準備ができたと思いますか？最後のゲーム化されたチャレンジをお試しください。
まだいくつかの点で不明な点がある場合は、読み進めてください。
今日、私たちが注目したい脆弱性は、ビジネスロジックの脆弱性です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生するもので、悪意のあるユーザがアプリケーションを悪用した場合、様々な種類の攻撃に対して脆弱になる可能性があります。各アプリケーションに実装されている目的や機能に応じて、ビジネスロジックの欠陥は、特権の昇格、不適切なリソースの使用、あるいは意図しない数多くのビジネスプロセスの実行を可能にするかもしれません。
多くの脆弱性とは異なり、ビジネスロジックルールの不正な実装は驚くほど巧妙です。そのため、アプリケーションやコードに紛れ込まないように、特別な注意を払う必要があります。
ビジネスロジックの欠陥の例としてはどのようなものがありますか？
ビジネスロジックの欠陥を誘発することがいかに簡単であるかの例として、Docker Composeファイルで定義されたDocker環境の次の例を考えてみましょう。コンテナが機能を実行できるように準備するために、開発者は次の例のようにDocker Composeファイルで定義された標準的なリソースポリシーを使用するかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
表面的には問題ないように見えますが、このコンテナのリソースポリシーは、リソースの使用を適切に制限していません。攻撃者は、このビジネスロジックの欠陥を利用して、サービス拒否（DoS）攻撃を実行することができます。
ユーザーが多くのリソースを占有することを制限するために、開発者は各コンテナがサポートできる内容をより明確に定義しようとするかもしれません。そのため、新しいコードには配置制約が含まれているかもしれません。
デプロイ：
リソース。
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コンテナが使用できるリソースの量を制限することがベストプラクティスです。具体的には、limitセクションで、Dockerコンテナが使用できるCPUの数とメモリの量を指定する必要があります。例としては、次のようになります。
デプロイ：
リソース。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
memory:50M
上記の例のようなコードをポリシーとして使用することで、ビジネスロジック上の大きな欠陥を環境から取り除き、DoS攻撃を防ぐことができます。これは、仮に攻撃者がDockerコンテナの1つを侵害したとしても機能します。その場合でも、攻撃者はその足場を利用してリソースを枯渇させることはできません。
脅威のモデル化は、さまざまな攻撃がどのように行われるかを定義し、ビジネスロジックのルールを使用して攻撃を防止・制限することで有効です。また、コンプライアンスルールや既知の不正使用事例に基づいてテストを行うことで、見落としがちなビジネスロジックの欠陥を発見することができます。
ビジネスロジックの欠陥は、アプリケーションに忍び込む可能性のある最も巧妙な脆弱性の一つですが、注目を集める他のリスクに劣らず危険です。ビジネスロジックの欠陥がどのようにして発生するかを知り、ベストプラクティスを用いることで、アプリケーションの開発段階ではそのような脆弱性を排除することができ、本番環境ではそのような脆弱性を悪用する方法を熟知した攻撃者に悪用されることはありません。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、さらに詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームでは、このIaCチャレンジのデモを試すことができ、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。
マティアス・マドゥ博士
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Codeers Conquer Security Infrastructure as Codeシリーズ - ビジネスロジック
さて、これで（今のところ）終わりです。Infrastructure as Codeシリーズは今回で終了となります。Docker、Ansible、Kubernetes、Terraform、CloudFormationなどのセキュリティ問題を楽しく攻略していただけたでしょうか。
これで自分のスキルを試す準備ができたと思いますか？最後のゲーム化されたチャレンジをお試しください。
まだいくつかの点で不明な点がある場合は、読み進めてください。
今日、私たちが注目したい脆弱性は、ビジネスロジックの脆弱性です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生するもので、悪意のあるユーザがアプリケーションを悪用した場合、様々な種類の攻撃に対して脆弱になる可能性があります。各アプリケーションに実装されている目的や機能に応じて、ビジネスロジックの欠陥は、特権の昇格、不適切なリソースの使用、あるいは意図しない数多くのビジネスプロセスの実行を可能にするかもしれません。
多くの脆弱性とは異なり、ビジネスロジックルールの不正な実装は驚くほど巧妙です。そのため、アプリケーションやコードに紛れ込まないように、特別な注意を払う必要があります。
ビジネスロジックの欠陥の例としてはどのようなものがありますか？
ビジネスロジックの欠陥を誘発することがいかに簡単であるかの例として、Docker Composeファイルで定義されたDocker環境の次の例を考えてみましょう。コンテナが機能を実行できるように準備するために、開発者は次の例のようにDocker Composeファイルで定義された標準的なリソースポリシーを使用するかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
表面的には問題ないように見えますが、このコンテナのリソースポリシーは、リソースの使用を適切に制限していません。攻撃者は、このビジネスロジックの欠陥を利用して、サービス拒否（DoS）攻撃を実行することができます。
ユーザーが多くのリソースを占有することを制限するために、開発者は各コンテナがサポートできる内容をより明確に定義しようとするかもしれません。そのため、新しいコードには配置制約が含まれているかもしれません。
デプロイ：
リソース。
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コンテナが使用できるリソースの量を制限することがベストプラクティスです。具体的には、limitセクションで、Dockerコンテナが使用できるCPUの数とメモリの量を指定する必要があります。例としては、次のようになります。
デプロイ：
リソース。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
memory:50M
上記の例のようなコードをポリシーとして使用することで、ビジネスロジック上の大きな欠陥を環境から取り除き、DoS攻撃を防ぐことができます。これは、仮に攻撃者がDockerコンテナの1つを侵害したとしても機能します。その場合でも、攻撃者はその足場を利用してリソースを枯渇させることはできません。
脅威のモデル化は、さまざまな攻撃がどのように行われるかを定義し、ビジネスロジックのルールを使用して攻撃を防止・制限することで有効です。また、コンプライアンスルールや既知の不正使用事例に基づいてテストを行うことで、見落としがちなビジネスロジックの欠陥を発見することができます。
ビジネスロジックの欠陥は、アプリケーションに忍び込む可能性のある最も巧妙な脆弱性の一つですが、注目を集める他のリスクに劣らず危険です。ビジネスロジックの欠陥がどのようにして発生するかを知り、ベストプラクティスを用いることで、アプリケーションの開発段階ではそのような脆弱性を排除することができ、本番環境ではそのような脆弱性を悪用する方法を熟知した攻撃者に悪用されることはありません。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、さらに詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームでは、このIaCチャレンジのデモを試すことができ、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。
