セキュリティで保護されたアプリケーションを Azure 上で設計する

この記事では、クラウド向けのアプリケーションを設計するときに考慮すべきセキュリティ アクティビティと制御について説明します。 Microsoft セキュリティ開発ライフサイクル (SDL) の要件と設計のフェーズ中に考慮すべきセキュリティの質問と概念に加えて、トレーニング用のリソースについて説明します。 目標は、より安全なアプリケーションの設計に使用できるアクティビティと Azure サービスの定義を手助けすることです。

この記事では、次の SDL フェーズについて説明します。

• トレーニング
• 必要条件
• デザイン

トレーニング

クラウド アプリケーションの開発を開始する前に、Azure のセキュリティとプライバシーについて理解する時間をとってください。 この手順を実行することで、アプリケーションの悪用可能な脆弱性の重大度と数を減らすことができます。 絶えず変化する脅威の状況に適切に対応するための準備がさらに整います。

トレーニング段階で次のリソースを使用して、開発者が利用できる Azure のサービスと Azure でのセキュリティのベスト プラクティスを理解してください。

• Azure の開発者ガイドでは、Azure の使用を開始する方法を説明しています。 このガイドでは、アプリケーションの実行、データの格納、インテリジェンスの組み込み、IoT アプリの構築、およびソリューションのデプロイを、より効率的かつ安全な方法で行うために使用できるサービスについて説明しています。

• Azure 開発者向けファースト ステップ ガイドでは、開発のニーズに対応するために Azure プラットフォームの使用を検討している開発者に必要不可欠な情報を提供しています。

• SDK/ツールでは、Azure で使用できるツールについて説明しています。

• Azure DevOps Services では、開発用の共同作業ツールを提供しています。 これらのツールには、高性能パイプライン、無料の Git リポジトリ、構成可能なかんばんボード、広範囲で自動化されたクラウドベースのロード テスト機能などがあります。 DevOps リソース センターでは、DevOps 手法、Git バージョン管理、アジャイル方式、Microsoft での DevOps の取り組み、独自の DevOps の進行状況を評価するための方法を学習するためのリソースがまとめられています。

• 「運用環境に移行する前にセキュリティ面で考慮すべき項目上位 5」では、Azure 上の Web アプリケーションをセキュリティで保護して、最も一般的で危険な Web アプリケーションへの攻撃からアプリを保護するのに役立つ方法が示されています。

• Secure DevOps Kit for Azure は、オートメーションを広範に使用する DevOps チームの包括的な Azure サブスクリプションとリソースのセキュリティのニーズに対応した、スクリプト、ツール、拡張機能、およびオートメーションのコレクションです。 Secure DevOps Kit for Azure では、ネイティブの DevOps ワークフローにセキュリティをスムーズに統合する方法を示すことができます。 このキットはセキュリティ検証テスト (SVT) などのツールに対応し、これにより開発者は、コーディングと初期の開発の段階で安全なコードを記述し、クラウド アプリケーションの安全な構成をテストすることができます。

• Azure セキュリティに関するベスト プラクティスとパターン - Azure を利用してクラウド ソリューションを設計、デプロイ、管理するときに使用するセキュリティのベスト プラクティスのコレクション。 ガイダンスは、IT プロフェッショナル向けに用意されています。 これには、セキュリティで保護された Azure ソリューションの構築とデプロイを行う設計者、アーキテクト、開発者、テスト担当者が含まれます。

必要条件

要件定義フェーズは、そのアプリケーションがどのようなアプリケーションで、リリースされたときに何を実行するかを定義する際の重要なステップです。 また、要件フェーズは、アプリケーションに組み込むセキュリティ制御について考慮するタイミングでもあります。 また、このフェーズの間に、セキュリティで保護されたアプリケーションを確実にリリースおよびデプロイするために SDL 全体を通して行う手順も開始します。

セキュリティとプライバシーの問題について考慮する

このフェーズは、基本的なセキュリティとプライバシーの問題を考慮するのに最適なタイミングです。 プロジェクトの開始時にセキュリティとプライバシーの許容可能なレベルを定義すると、チームで次のことができます。

• セキュリティの問題に関連するリスクを理解する。
• 開発時にセキュリティ バグを特定して修正する。
• プロジェクト全体を通して確立されたレベルのセキュリティとプライバシーを適用する。

アプリケーションの要件を記述する際は、必ず、アプリケーションやデータを保護するのに役立つセキュリティ制御を考慮してください。

セキュリティの質問をする

次のようなセキュリティの質問をしてください。

• アプリケーションには機密データが含まれているか?

• アプリケーションで収集または格納するデータは、米国連邦金融機関検査協議会 (FFIEC) や Payment Card IndustryData Security Standards (PCI DSS) などの業界標準およびコンプライアンス プログラムに準拠する必要があるデータか?

• アプリケーションで収集または含まれている個人や顧客の機密データは、そのままで、または他の情報と共に使用することで、個人を特定したり、接触したり、探し当てたりできる機密データか?

• アプリケーションで収集または含まれているデータは、個人の医療、教育、財務、または雇用の情報にアクセスするために使用できるデータか? 要件フェーズ中にデータの機密度を特定することは、データを分類し、アプリケーションに使用するデータの保護方法を特定するのに役立ちます。

• データはどこに、どのように格納するか? アプリケーションで予期しない変更 (低速の応答時間など) のために使用されるストレージ サービスを、どのように監視するかを検討してください。 詳細なデータを収集して、問題を徹底的に分析するために、ログに影響を与えることができるか?

• アプリケーションは一般に公開するのか、または内部専用にするのか? アプリケーションを一般に公開する場合は、収集されるデータが誤った方法で使用されないように、どのように保護するのか? アプリケーションを内部でのみ使用できるようにする場合は、組織内のアプリケーションにアクセスできるユーザーと、そのユーザーがアクセスできる期間を検討してください。

• アプリケーションの設計を開始する前に、ID モデルについて理解しているか? ユーザーが本人であること、およびユーザーに何をする権限があるかを判断できるか?

• アプリケーションは機密性の高いタスクや重要なタスク (送金、ドアの開錠、医薬品の配送など) を実行するか? 機密性の高いタスクを実行するユーザーがそのタスクを実行することを承認されていることを確認する方法と、その人が本人であることを認証する方法を検討してください。 承認 (AuthZ) は、認証済みのセキュリティ プリンシパルに対し、何かを実行する権限を付与する行為です。 認証 (AuthN) は、当事者に正当な資格情報を要求する行為です。

• アプリケーションは、ユーザーにファイルや他のデータのアップロードまたはダウンロードを許可するといったリスクの高いソフトウェアのアクティビティを実行するか? アプリケーションがリスクの高いアクティビティを実行する場合は、アプリケーションによってユーザーが悪意のあるファイルやデータを処理しないようにする方法を検討してください。

OWASP の上位 10 件を確認する

OWASP の上位 10 件のアプリケーションのセキュリティ リスクを確認することを検討してください。 OWASP の上位 10 件は、Web アプリケーションに対する重大なセキュリティ上のリスクに対応しています。 これらのセキュリティ リスクを認識することが、アプリケーションでこれらのリスクを最小限に抑える要件と設計についての決定を下す際に役立ちます。

侵害防止のためのセキュリティ制御について検討することは重要です。 ただし、侵害を当然発生するものと考えることもできます。 侵害を想定することで、セキュリティに関する重要な質問に事前に答えを出すことができるため、次のような質問の答えを緊急時に出さなくても済みます。

• どのように攻撃を検出するのか?
• 攻撃や侵害がある場合はどうするのか?
• データの漏洩や改ざんなどの攻撃をどのように克服するのか?

デザイン

設計フェーズは、設計と機能の仕様のベスト プラクティスを確立するために不可欠です。 また、プロジェクト全体を通してセキュリティとプライバシーの問題を軽減するのに役立つリスク分析を実行するためにも不可欠です。

セキュリティ要件を整えて、安全な設計概念を使用すると、セキュリティ上の欠陥の可能性を回避したり最小限に抑えたりすることができます。 セキュリティ上の欠陥は、アプリケーションのリリース後にユーザーが悪意のあるアクションや予期しないアクションを実行できるようにする可能性がある、アプリケーションの設計ミスです。

また、設計フェーズでは、セキュリティを層状に適用する方法も検討してください。1 つのレベルの防御では必ずしも十分ではありません。 攻撃者が Web アプリケーション ファイアウォール (WAF) を通り抜けると、どうなるでしょう。 その攻撃に備えるには、別のセキュリティ制御が必要です。

これを踏まえて、セキュリティで保護されたアプリケーションを設計する際に対処すべき、次の安全な設計概念とセキュリティ制御について説明します。

• セキュリティで保護されたコーディング ライブラリとソフトウェア フレームワークを使用する。
• 脆弱性のあるコンポーネントをスキャンする。
• アプリケーション設計時に脅威モデリングを使用する。
• 攻撃の対象となる領域を減らす。
• 主要なセキュリティ境界として ID のポリシーを採用する。
• 重要なトランザクションには再認証を要求する。
• キー管理ソリューションを使用して、キー、資格情報、およびその他のシークレットをセキュリティで保護する。
• 機密データを保護する。
• フェールセーフ対策を実装する。
• エラーと例外の処理を活用する。
• ログ記録と警告機能を使用する。

セキュリティで保護されたコーディング ライブラリとソフトウェア フレームワークを使用する

開発では、セキュリティで保護されたコーディング ライブラリと、セキュリティが埋め込まれたソフトウェア フレームワークを使用します。 開発者は、セキュリティ制御をゼロから開発するのではなく、実証済みの既存の機能 (暗号化、入力のサニテーション、出力のエンコード、キーまたは接続文字列、およびセキュリティ制御とみなされるその他のもの) を使用できます。 これにより、セキュリティ関連の設計と実装の欠陥を防ぐことができます。

必ず、最新のバージョンのフレームワークと、そのフレームワークで使用できるすべてのセキュリティ機能を使用してください。 Microsoft は、すべての開発者がクラウド アプリケーションを提供するための、あらゆるプラットフォームまたは言語で動作する包括的な開発ツールのセットを提供しています。 さまざまな SDK から選択することで、任意の言語でコーディングすることができます。 フル機能の統合開発環境 (IDE) と、高度なデバッグ機能と組み込みの Azure サポートを備えたエディターを利用できます。

Microsoft は、Azure でのアプリケーションの開発に使用できるさまざまな言語、フレームワーク、およびツールを提供しています。 たとえば、.NET および .NET Core 開発者向けの Azure です。 提供されている言語とフレームワークごとに、すぐに使用を開始するのに役立つクイックスタート、チュートリアル、API リファレンスがあります。

Azure では、Web サイトと Web アプリケーションのホストに使用できるさまざまなサービスが提供されています。 これらのサービスにより、.NET、.NET Core、Java、Ruby、Node.js、PHP、Python のうち、使い慣れた言語で開発を行うことができます。 Azure App Service Web Apps (Web Apps) はこれらのサービスの 1 つです。

Web Apps は、アプリケーションに Microsoft Azure の機能を追加します。 これには、セキュリティ、負荷分散、自動スケール、および自動管理が含まれます。 また、パッケージ管理、ステージング環境、カスタム ドメイン、SSL 証明書、および Azure DevOps、GitHub、Docker Hub およびその他のソースからの継続的デプロイなど、Web Apps の DevOps 機能を利用することもできます。

Azure は、Web サイトと Web アプリケーションのホストに使用できるその他のサービスを提供しています。 ほとんどの場合は、Web Apps が最適な方法になります。 マイクロサービス アーキテクチャの場合は、Azure Service Fabric を検討してください。 また、コードの実行に使用する VM をより細かく制御する必要がある場合は、Azure Virtual Machines の利用をご検討ください。 これらの Azure サービスから適切なサービスを選択する方法の詳細については、「Azure App Service、Virtual Machines、Service Fabric、Cloud Services の比較」を参照してください。

コンポーネントに更新を適用する

脆弱性を防ぐためには、クライアント側とサーバー側の両方のコンポーネント (フレームワークやライブラリなど) と、更新に対するそれらの依存関係のインベントリを、絶えず作成してください。 新たな脆弱性と更新されたソフトウェア バージョンは、絶えずリリースされます。 使用しているライブラリやコンポーネントに対する更新や構成変更を監視、トリアージ、および適用するための継続的な計画を、必ず用意してください。

ツールに関する推奨事項については、Open Web Application Security Project (OWASP) の既知の脆弱性のあるコンポーネントの使用に関するページを参照してください。 また、使用するコンポーネントに関連するセキュリティの脆弱性に関するメールの受信を登録することもできます。

アプリケーション設計時に脅威モデリングを使用する

脅威モデリングは、ビジネスやアプリケーションに対する潜在的なセキュリティ上の脅威を特定して、確実に適切な軽減策を用意するプロセスです。 SDL には、潜在的な問題の解決が比較的容易でコスト効率に優れている場合は、設計フェーズでチームが脅威モデリングに参加すべきと規定されています。 設計フェーズで脅威モデリングを使用すれば、開発の総コストを大幅に削減できます。

脅威モデリングのプロセスの促進を支援するために、Microsoft では、セキュリティのエキスパートではない人を念頭に置いて SDL Threat Modeling Tool を設計しました。 このツールは、脅威モデルの作成と分析の方法についての明確なガイダンスを提供することで、すべての開発者がより簡単に脅威モデリングを行えるようにします。

アプリケーションの設計をモデリングし、すべての信頼境界線を超える STRIDE 脅威 (スプーフィング、改ざん、否認、情報漏えい、サービス拒否、および特権の昇格) を列挙することは、早い段階で設計エラーを検出するための効果的な方法であると証明されています。 次の表は STRIDE 脅威の一覧と Azure が提供する機能を使用した軽減策の例です。 これらの軽減策はあらゆる状況で機能するわけではありません。

攻撃の対象となる領域を減らす

攻撃の対象となる領域は、潜在的な脆弱性が発生する可能性のある場所全体のことです。 このドキュメントでは、アプリケーションの攻撃対象領域について説明します。 アプリケーションを攻撃から保護することに焦点を当てています。 攻撃対象領域を最小限に抑える簡単で迅速な方法は、アプリケーションから未使用のリソースとコードを削除することです。 アプリケーションが小さいほど、攻撃対象る領域が小さくなります。 たとえば、次のものを削除します。

• まだリリースされていない機能のコード。
• デバッグのサポート コード。
• 使用されていない、または非推奨になっているネットワーク インターフェイスとプロトコル。
• 使用していない仮想マシンとその他のリソース。

リソースの定期的なクリーンアップを行い、未使用のコードを確実に削除することは、悪意のあるアクターによる攻撃の可能性を確実に減らすための優れた方法です。

攻撃対象領域を減らすためのさらに詳細で徹底した方法は、攻撃対象領域の分析を実施することです。 攻撃対象領域の分析により、システムの中でセキュリティの脆弱性を確認してテストする必要がある部分を特定することができます。

攻撃対象領域の分析の目的は、開発者やセキュリティの専門家がアプリケーションのどの部分が攻撃にさらされているのかを認識できるように、アプリケーション内のリスクのある領域を把握することです。 これにより、この可能性を最小限に抑える方法がわかり、攻撃対象領域がいつどのように変化し、これがリスクの観点から何を意味するかを追跡できます。

攻撃対象領域の分析により、次のことを確認できます。

• システムの中でセキュリティの脆弱性をレビューしてテストする必要がある機能と部分。
• 多層防御による保護を必要とする危険度の高いコードの領域 (システムの中の保護する必要のある部分)。
• 攻撃対象領域の変更により、脅威の評価の更新が必要になるタイミング。

攻撃者が潜在的に脆弱なスポットや脆弱性を悪用する可能性を減らすには、アプリケーションの攻撃対象領域全体を徹底的に分析する必要があります。 これには、システム サービスへのアクセスを無効化または制限したり、最小特権の原則を適用したり、可能な限り多層型防御を採用したりすることも含まれます。

SDL の検証フェーズで、攻撃対象領域のレビューの実施について説明します。

主要なセキュリティ境界として ID のポリシーを採用

クラウド アプリケーションを設計するときは、セキュリティ境界のフォーカスを、ネットワークを中心としたアプローチから ID を中心としたアプローチに拡大することが重要です。 これまでは、オンプレミスの主要なセキュリティ境界は、組織のネットワークでした。 オンプレミスのほとんどのセキュリティ設計では、主要なセキュリティの中心としてネットワークが使用されています。 クラウド アプリケーションでは、ID を主要なセキュリティ境界と考えることによって、より充実したサービスを提供します。

Web アプリケーションの開発のための ID 中心のアプローチを開発するために実行できることは、次のとおりです。

• ユーザーに多要素認証を適用します。
• 強力な認証と承認のプラットフォームを使用する。
• 最小特権の原則を適用する。
• Just-In-Time アクセスを実装する。

ユーザーに多要素認証を適用する

2 要素認証を使用します。 2 要素認証はユーザー名や認証パスワードの種類に固有のセキュリティ脆弱性が回避されるため、認証と承認において現在標準になっています。 Azure 管理インターフェイス (Azure portal/リモート PowerShell) と、顧客に提供されるサービスへのアクセスは、Microsoft Entra 多要素認証を使用するように設計して構成する必要があります。

強力な認証と承認のプラットフォームを使用する

カスタム コードではなく、プラットフォームが提供する認証と承認のメカニズムを使用するようにします。 これは、カスタム認証コードの開発ではエラーが生じやすいためです。 商用コード (たとえば Microsoft のコード) は、通常はセキュリティが徹底的にレビューされています。 Microsoft Entra ID (Microsoft Entra ID) は、ID とアクセスの管理のための Azure ソリューションです。 安全な開発には、Microsoft Entra の以下のツールとサービスが役立ちます。

• Microsoft ID プラットフォームは、ユーザーが安全にサインインするアプリを構築するために、開発者が使用する一連のコンポーネントです。 このプラットフォームでは、シングル テナントの基幹業務 (LOB) アプリを構築する開発者、およびマルチテナント アプリの開発を目指す開発者を支援します。 基本的なサインインに加えて、Microsoft ID プラットフォームを使用して構築されたアプリによって、Microsoft API とカスタム API を呼び出すことができます。 Microsoft ID プラットフォームでは、OAuth 2.0 や OpenID Connect など業界標準のプロトコルがサポートされています。

• Azure Active Directory B2C (Azure AD B2C) は、アプリケーション使用時に顧客がサインアップ、サインイン、プロファイル管理の方法をカスタマイズして制御するために使用する ID 管理サービスです。 ここでは、特に iOS、Android、.NET 用に開発されたアプリケーションが対象です。 Azure AD B2C は、これらのアクションを可能にする一方で、顧客 ID を保護します。

最小特権の原則を適用する

最小特権の概念は、ユーザーに、自分のジョブ以上のことを実行しないために必要な正確なアクセス権と制御を提供することを意味します。

ソフトウェア開発者にドメイン管理者権限は必要でしょうか。 管理アシスタントに、自分のパーソナル コンピューターに対する管理制御へのアクセス権は必要でしょうか。 ソフトウェアへのアクセス権を評価することもまったく同様です。 Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、ユーザーにアプリケーションのさまざまな機能や権限を付与する場合、すべてのユーザーにすべてへのアクセス権は付与しません。 アクセスをロールごとに必要なものに制限することで、セキュリティの問題が発生するリスクを制限します。

アプリケーションがそのアクセス パターン全体を通して最小特権を適用するようにしてください。

Just-In-Time アクセスを実装する

Just-In-Time (JIT) アクセスを実装して、権限が公開される時間をさらに短縮します。 Microsoft Entra Privileged Identity Management を使用して次のことを行います。

• ユーザーに JIT のみを必要とするアクセス許可を付与します。
• 権限が自動的に取り消される、短縮された期間のロールを割り当てます。

重要なトランザクションには再認証を要求する

クロスサイト リクエスト フォージェリ (XSRF または CSRF) は、Web でホストされるアプリに対する攻撃であり、悪意のある Web アプリが、クライアント ブラウザーとそのブラウザーが信頼する Web アプリの間のやり取りに影響を及ぼします。 クロスサイト リクエスト フォージェリ攻撃が起こり得るのは、Web ブラウザーが要求ごとにある種の認証トークンを自動的に Web サイトに送信するからです。 この種の悪用は、攻撃がユーザーの以前に認証されたセッションを利用するため、ワンクリック攻撃またはセッション ライディングとも呼ばれています。

このような攻撃を防御する最善の方法は、購入、アカウントの非アクティブ化、パスワードの変更などのすべての重要なトランザクションの前に、ユーザーしか提供できないものを提供するようユーザーに求めることです。 ユーザーに、パスワードの再入力、キャプチャの入力、またはユーザーだけが持っているシークレット トークンの送信を求めることもできます。 最も一般的なアプローチは、シークレット トークンです。

キー管理ソリューションを使用して、キー、資格情報、およびその他のシークレットをセキュリティで保護する

キーや資格情報の紛失は、よくある問題です。 資格情報やその他のシークレットを紛失するよりも悪い唯一のことは、権限のない第三者がキーや資格情報にアクセスすることです。 攻撃者は、自動化された方法や手動の方法を利用して、GitHub などのコード レポジトリに格納されているキーやシークレットを見つける可能性があります。 これらのパブリックなコード レポジトリやその他のサーバーには、キーやシークレットを格納しないでください。

キー、証明書、シークレット、および接続文字列は、常にキー管理ソリューションに格納してください。 キーやシークレットをハードウェア セキュリティ モジュール (HSM) に格納する一元化されたソリューションを使用できます。 Azure では、Azure Key Vault によりクラウドで HSM を提供しています。

Azure Key Vault はシークレット ストアであり、アプリケーション シークレットを格納するための一元的なクラウド サービスです。 Key Vault は、アプリケーションのシークレットを中央の 1 か所に保存し、アクセスをセキュリティで保護し、アクセス許可を制御し、アクセスをログに記録することで、機密データを保護します。

シークレットは個々のコンテナーに格納されています。 各コンテナーには、アクセスを制御するための独自の構成とセキュリティ ポリシーがあります。 データにアクセスするには、REST API を使用するか、クライアントのほとんどのプログラミング言語で利用可能な SDK を使用します。

機密データを保護する

データの保護は、セキュリティ戦略の重要な部分です。 データの分類とデータ保護の識別には、データのセキュリティを考慮してアプリを設計できるようにする必要があります。 格納されたデータを機密度とビジネスへの影響によって分類 (カテゴリ化) することで、開発者がデータに関連付けられているリスクを判断することができます。

データ形式を設計するときに、該当するすべてのデータに機密情報としてラベルを付けます。 アプリケーションが該当するデータを必ず機密として扱うようにします。 機密データを保護するには、以下のプラクティスが役立ちます。

• 暗号化を使用する。
• キーやパスワードなどのシークレットをハード コーディングしない。
• アクセス制御と監査の準備ができていることを確認する。

暗号化を使用する

データの保護は、セキュリティ戦略の重要な部分である必要があります。 データがデータベースに格納されている場合、または異なる場所の間で行き来する場合は、保存データの暗号化 (データベース内にある場合) と転送中のデータの暗号化 (ユーザー、データベース、API、またはサービス エンドポイントの間で転送中の場合) を使用します。 データの交換には、常に SSL/TLS プロトコルを使うことをお勧めします。 暗号化には必ず最新バージョンの TLS (現時点ではバージョン 1.2) を使用してください 。

ハード コーディングしない

ソフトウェアにはハードコーディングしてはならないものがあります。 いくつかの例として、ホスト名または IP アドレス、URL、メール アドレス、ユーザー名、パスワード、ストレージ アカウント キー、およびその他の暗号化キーがあります。 コードのコメント セクションを含み、コードにハードコーディングできるものとできないものに関する要件を実装することを検討してください。

コードにコメントを入力するときは、機密情報を保存しないようにしてください。 これには、メール アドレス、パスワード、接続文字列、組織内の人しか知らないアプリケーションに関する情報、およびアプリケーションや組織を攻撃する攻撃者を有利な立場にする可能性のあるその他のものが含まれます。

基本的には、開発プロジェクトに含まれるものはすべて、デプロイ時に公開されると考えてください。 プロジェクトにはいかなる機密データも含めないでください。

Azure Key Vault については既に説明しました。 Key Vault を使用すれば、キーやパスワードなどのシークレットをハードコーディングするのではなく、格納することができます。 Key Vault を Azure リソースのマネージド ID と組み合わせて使用すると、Azure の Web アプリで、ソース管理や構成にシークレットを格納することなく、シークレットの構成値に簡単かつ安全にアクセスすることができます。 詳細については、「Azure Key Vault を使用してサーバー アプリでシークレットを管理する」を参照してください。

フェールセーフ対策を実装する

アプリケーションは、実行中に発生するエラーを一貫した方法で処理可能である必要があります。 アプリケーションは、すべてのエラーをキャッチして、フェールセーフまたは解決済みにする必要があります。

また、疑わしいアクティビティや悪意のあるアクティビティを識別するために、必ず十分なユーザー コンテキストでエラーをログに記録する必要もあります。 ログは、フォレンジック分析の遅延を許容するのに十分な時間、保持される必要があります。 ログは、ログ管理ソリューションで簡単に使用できる形式である必要があります。 セキュリティに関連するエラーのアラートは、必ずトリガーしてください。 ログ記録と監視が不十分では、攻撃者がさらにシステムを攻撃して、攻撃を持続できるようにしてしまいます。

エラーと例外の処理を活用する

適切なエラーと例外処理の実装は、防御的なコーディングの重要な部分です。 システムを信頼性が高く安全なものにするには、エラーと例外の処理が不可欠です。 エラー処理の誤りは、攻撃者に情報を漏らしたり、攻撃者がプラットフォームや設計についてさらに理解するのを手助けしたりといった、さまざまな種類のセキュリティの脆弱性を引き起こす可能性があります。

次のことを確認します。

• コード内で try/catch ブロックが重複しないように、一元的な方法で例外を処理します。

• 予期しないすべての動作は、アプリケーション内で処理されるようにします。

• ユーザーに表示されるメッセージは、重要なデータを漏えいすることなく、問題を説明するのに十分な情報を提供するようにします。

• 例外はログに記録され、フォレンジクスやインシデント対応チームが調査するのに十分な情報を提供するようにします。

Azure Logic Apps は、依存システムが原因となるエラーと例外の処理のための最上級のエクスペリエンスを提供します。 Logic Apps を使用すると、企業や組織の全体でアプリ、データ、システム、サービスを統合するタスクとプロセスを自動化するワークフローを作成することができます。

ログ記録と警告機能を使用する

問題について適切なタイミングで把握するためには、セキュリティ調査のためにセキュリティの問題のログを記録し、問題に関する警告をトリガーします。 すべてのコンポーネントで監査とログ記録を有効にします。 監査ログでは、ユーザー コンテキストをキャプチャし、すべての重要なデータを識別する必要があります。

ユーザーからサイトに送信される機密データをログに記録していないことを確認してください。 機密データの例は次のとおりです。

• ユーザーの資格情報
• 社会保障番号やその他の識別情報
• クレジット カード番号やその他の金融情報
• 健康に関する情報
• 暗号化された情報の復号化に使用できる秘密キーやその他のデータ
• アプリケーションへのさらに効果的な攻撃に使用される可能性があるシステムまたはアプリケーションの情報

アプリケーションが、ユーザーのログイン、パスワードのリセット、パスワードの変更、アカウントのロックアウト、ユーザー登録などのユーザー管理イベントの成功と失敗を監視していることを確認します。 これらのイベントのログを記録すると、疑わしい動作を検出して対処するのに役立ちます。 だれがアプリケーションにアクセスしているかといった、操作データを収集することもできます。

次のステップ

次の記事では、セキュリティで保護されたアプリケーションを開発してデプロイするのに役立つセキュリティ制御とアクティビティが推奨されています。

• セキュリティで保護されたアプリケーションを開発する
• セキュリティで保護されたアプリケーションをデプロイする