ホームページ > Java > &#&チュートリアル > Web アプリケーションのセキュリティを確保する方法を教えてください

Web アプリケーションのセキュリティを確保する方法を教えてください

怪我咯
リリース: 2017-06-25 10:19:05
オリジナル
2619 人が閲覧しました

Web アプリケーションは、今日のほとんどのエンタープライズ アプリケーションの最前線にあります。 Web アプリケーションは、複雑なハイブリッド アーキテクチャでさまざまな機能を実行できます。最新のクラウド テクノロジ上で実行されるサービス指向のソリューションから、古い多層 Web アプリケーション、顧客がメインフレーム上のレガシー アプリケーションにアクセスできる Web ポータルまで、さまざまなアプリケーションが含まれています。

これらの複雑な Web アプリケーションに関連するリスクの管理は企業にとって避けられない要件であり、これらの Web アプリケーションを実行する基盤となるコードのセキュリティは、企業のアプリケーションで利用できるデータのリスク体制に直接影響します。残念ながら、Web アプリケーション向けに反復可能で効率的なセキュリティ手法を開発するのは簡単な作業ではありません。多くの組織は、Web アプリケーション ファイアウォールや侵入防止システムなどのセキュリティ制御を提供するためにポストプロダクション ソリューションを使用しようとしています。

しかし、ライフサイクルの運用段階まで待ってセキュリティメカニズムを導入するのは少し遅すぎますし、その効果はあまりにも小さいです。設計やアーキテクチャの問題は、アプリケーションが実稼働状態になるまで待って非常にコストがかかるよりも、ライフサイクルの早い段階で解決する方が簡単です。 Web アプリケーションのセキュリティの脆弱性はデータ漏洩、ポリシー違反につながる可能性があり、展開後のパッチ適用や包括的なコード修復により全体のコストが大幅に増加する可能性があります。

有効性と効率性を確保するには、Webアプリケーションのセキュリティは要件定義フェーズから最終的な受け入れフェーズまで開始する必要があります。このアプローチでは、すべてのデザイナーがプロセス全体を通じてチームとして協力できる必要があります。実装やテストなどのフェーズでは、戦略に従った自動化ツールを使用すると、反復可能なテストがサポートされ、テスト プロセスが標準化されるため、開発サイクルの短縮につながります。

開発プロセスの初期段階からセキュリティを組み込むことは、複雑である必要はありません。開発サイクル全体を通じてセキュリティのチェックとバランスを実装すると、リリース サイクルが短縮され、Web アプリケーションの脆弱性を大幅に軽減できます。

開発サイクルの後半でセキュリティテストを実装するとコストが高くなります

開発プロセスにセキュリティチェックポイントを組み込むと、実際に全体の納期を短縮できます。直観に反するように聞こえるかもしれませんが、Web アプリケーションを運用環境にデプロイした後に設計エラーやコーディング エラーを修正するのにかかるコストは非常に高くなります。

たとえば、多くの開発環境では、セキュリティと監査の専門家が開発サイクルの最後に現れる傾向があります。この時点でアプリケーションは完了しており、遅延は不必要なボトルネックとみなされます。ソフトウェア製品を迅速に展開するという企業からの強い圧力により、セキュリティ管理が見落とされる可能性があり、その結果、Web アプリケーションが適切なセキュリティ レビューを受けられなくなります。この非常に時間に敏感な環境では、たとえスキャン ツールが検証や優先順位付けを行わずに多数の脆弱性を報告したとしても、そのようなスキャンは良いことよりも害を及ぼす可能性があります。

開発サイクル全体を通して協力するのではなく、開発プロセスの後半でセキュリティ監査を実行すると、特に重大なバグが発見された場合、リリース時期の遅れにつながる可能性があります。開発サイクルの後半で設計およびコーディングのエラーを修正するコストは、早期にエラーを発見するコストよりもはるかに高くなります。米国科学財団の調査によると、ソフトウェアの重大な問題が要件および設計段階で発見され修正された場合、ソフトウェアの運用開始後に問題が発見された場合に比べて、コストは約 100 分の 1 に削減されると試算されています。

Web アプリケーションにセキュリティを組み込む場合、ほとんどの場合、目標は、侵入できない Web アプリケーションを構築したり、考えられるすべての脆弱性を排除したりすることではありません。代わりに、必要な特性を Web アプリケーションの許容されるリスク プロファイルと一致させることを目標にする必要があります。 Web アプリケーションの開発サイクル全体を通じて、目標はソフトウェア保証を達成することである必要があります。つまり、特定の Web アプリケーションに適した機能と感度のレベルであり、たとえ次のような場合でも、ソフトウェアが必要な特性を達成し続けることを合理的に保証します。ソフトウェアが攻撃される可能性があります。

統合アプローチの利点

異なるグループの開発者がチームとして協力すると、Web アプリケーション開発プロセスの効率が高まります。セキュリティ専門家は、ビジネス リーダーがソフトウェア リスクをまったく理解していないことをよく嘆いていますが、セキュリティ専門家がビジネス リスクに精通していることも重要です。適切なレベルのソフトウェア保証を備えた Web アプリケーションを構築するには、ビジネス ニーズ、可用性、セキュリティの間のリスク管理のトレードオフが必要です。適切なバランスを実現するには、すべての開発者のニーズを収集する必要があります。

ソフトウェア開発の開始時から、要件定義とアプリケーション設計では、機能要件やビジネスニーズだけでなく、セキュリティ要件も考慮する必要があります。この情報は、コードを記述する前に設計者やソフトウェア開発者に伝える必要があります。このアプローチにより、ほとんどまたはすべてのセキュリティ設計の脆弱性とアーキテクチャの脆弱性を防ぐことができます。

ただし、セキュリティを重視したソフトウェア設計は、Web アプリケーションに関連するすべての脆弱性を排除するわけではありません。アプリケーションの設計中にセキュリティの脆弱性が導入されないように、開発者自身が安全なコーディング技術のトレーニングを受ける必要があります。安全な方法で開発言語とランタイム環境についての洞察を開発者に提供することで、より良いコーディング手法をサポートし、最終的な Web アプリケーションのバグを軽減できます。設計プロセスにセキュリティを組み込むことによるもう 1 つの効率上の利点は、要件と設計中に誤用シナリオを確立できることです。テスト段階と受信段階でこれを行うと、時間が節約され、ボトルネックの解消に役立ちます。

統合総合テストのメリット

ソフトウェアテストの統合総合分析手法は、効率を大幅に向上させることができます。統合開発環境用の特定のプラグインは、ユーザーのコード内でコーディング エラーを検出した場合にプログラマーに警告します。 「ホワイト ボックス」テストとしても知られる静的分析は、最終製品に組み立てられる前に、さまざまなモジュールに対して開発者と監査人が使用する手法です。静的分析では、アプリケーションをコード レベルで内部関係者が観察できます。静的分析は、構文エラーやコードレベルの欠陥を発見するのには効果的ですが、欠陥が悪用可能な脆弱性をもたらすかどうかを判断するのには適していません。

アプリケーションが攻撃に対して脆弱かどうかを検証するには、動的分析と手動侵入テストが効果的です。 「ブラックボックステスト」とも呼ばれ、主に外部者によるアプリケーションの検査と分析を行い、攻撃者が脆弱性を悪用しやすいかどうかを確認します。ただし、動的テスト手法は、ソフトウェア開発の後期段階、つまり生成後の段階でのみ使用できます。動的テストのもう 1 つの制限は、コード内で脆弱性の原因となっているコードのソースを見つけるのが難しい場合があることです。

だからこそ、静的テストと動的テストを「グレーボックス」で組み合わせるか、ハイブリッドテストのために組み合わせたアプローチを行うことが重要です。コードレベルの内部検査の結果を動的外部検査と組み合わせることで、両方のテクノロジーの長所を活用できます。静的および動的評価ツールを使用すると、管理者と開発者はアプリケーション、モジュール、脆弱性に優先順位を付け、最も影響の大きい問題に最初に対処できます。複合分析アプローチのもう 1 つの利点は、動的テストによって特定された脆弱性を、静的ツールを使用してコードの特定の行またはブロックまで追跡できることです。これにより、テスト チームと開発チーム間の協力的なコミュニケーションが促進され、セキュリティとテストの専門家が具体的で実用的なトラブルシューティング ガイダンスを開発者に提供しやすくなります。

ソフトウェアのライフサイクルにセキュリティを組み込む: 実践的なアプローチ

セキュリティを構築するには、人材、プロセス、テクノロジーと手法が必要です。 Web アプリケーションのセキュリティを強化するプロセスの自動化に役立つツールは数多くありますが、Web アプリケーションを作成してテストするための適切なプロセスと訓練を受けた担当者がなければ、どのツールも真の効果を発揮することはできません。

このプロセスには、正式なソフトウェア開発サイクルと公開された戦略が含まれている必要があります。さらに、すべての開発者の役割を確立し、検査および監督の責任を割り当てることが重要です。あらゆる段階でリスク管理に対処できるように、ソフトウェア開発サイクルのあらゆる段階でセキュリティとビジネスを表現する必要があります。

ソフトウェア開発サイクル全体において、有益かつ永遠のテーマは教育です。教育は開発者にとって重要であり、Web アプリケーション開発に携わるすべての人に利益をもたらします。なぜなら、セキュリティ意識はトップダウンとボトムアップの両方で行う必要があるからです。 Web アプリケーションの脆弱性がビジネスに与える影響についてマネージャーを教育することの重要性を過小評価しないでください。 Web アプリケーションがクロスサイト リクエスト フォージェリ (CSRF) に対して脆弱であることを幹部に伝えるのは混乱するかもしれませんが、ソフトウェアのバグが顧客データの漏洩にどのようにつながるかを示すと、セキュリティ上の実際の影響を理解するのに役立ちます。ウェブアプリケーション。さまざまなコスト削減の可能性を示すために、具体的なケースと指標を準備する必要があります。たとえば、開発者のトレーニングと IDE の静的分析プラグインへの投資により、ソフトウェア アプリケーションのコードを検査する前にデータ漏洩の原因を防止できることを実証します。

監査人や評価者は、一般的なコーディング エラーについて学び、その結果を評価し、バックエンド サポート システム、既存のセキュリティ制御、Web アプリケーション環境の一部であるサービスやアプリケーションなどの Web アプリケーションの「エコシステム」と対話できます。 .) 関連の依存関係。テスターと品質評価の専門家は、誤用のシナリオと、それが規格の適用とどのように異なるのかをよく理解し、安全性テストの結果を解釈する方法を理解し、必要に応じて結果に優先順位を付けることができる必要があります。

セキュリティとリスク管理を実装しながら効率を高める機会が存在するソフトウェア開発サイクルの特定のステップに焦点を当てます。

要件

Web アプリケーションの設計者は、機能要件やビジネス要件の定義には精通していますが、セキュリティ要件の定義方法を理解していない場合があります。この時点で、チーム全体が協力して、最終的な Web アプリケーションにとってどのセキュリティ制御が重要であるかを決定する必要があります。

セキュリティを要件フェーズに統合する手順

1. 会社のポリシー、コンプライアンス、規制要件に基づいてセキュリティ要件を議論し、定義します。

2. セキュリティチームと監査チームは、Webアプリケーションのビジネス要件と機能を評価し、テストと受け入れ中に誤用ケース(誤用シナリオ)の開発を開始する必要があります。

メリットは2つあり、1つはセキュリティや違反の問題を事前に解決または軽減できること、もう1つは展開時間を短縮できることです。

アーキテクチャとデザイン

Web アプリケーションのアーキテクチャとデザインが定義されたので、次のステップはセキュリティ問題を評価することです。このフェーズでは、コストがかかり、修正が困難な安全上の問題を、最も解決可能なタイミングで修正できます。コストのかかる間違いを防ぐために、プログラムのアーキテクチャをパフォーマンスとセキュリティの両方の観点から評価する必要があります。詳細な設計仕様は、どのようなセキュリティ制御を含めるべきか、およびアプリケーションのコンポーネントが完全な Web アプリケーションとどのように対話するかを開発者に示すためにまとめられています。

セキュリティをアーキテクチャと設計フェーズに統合する手順

1. 提案されたアーキテクチャと導入環境のリスク評価を実行し、設計がリスクを引き起こすかどうかを判断します。

2. アプリケーションが元のシステムと対話するときのセキュリティへの影響とリスク、および異なるコンポーネント、レイヤー、またはシステム間のデータフローのセキュリティ問題を評価します。

3. 実装または展開フェーズで対処する必要がある特定の危険にさらされる問題 (つまり、アプリケーションが展開される方法と場所に依存する脆弱性) についてコメントします。

4. マッシュアップ、SOA、パートナーサービスとの相互作用によって引き起こされる依存関係と脆弱性を考慮します。最終設計をセキュリティと監査に提出し、セキュリティ テスト計画と悪用シナリオを特定します。

その利点は次の 5 つの側面に反映されます:

1. リスク評価分析プロセスと再利用可能なリスク評価モデルを慎重に調整できます。

2. アーキテクチャ環境や導入環境に起因するリスクを早期に特定できる。

3. 再利用可能な誤用ケースにより、テスト段階での時間を節約できます。

4. 特定の設計の脆弱性を軽減します。

5. 必要に応じて、リスクをもたらすアーキテクチャ上の制約を調整または変更することができ、リスクを完全に排除できない場合は、補償制御を使用してリスク軽減戦略を定義することもできます。

コードの実行とコンパイル

開発者がコードの作成を開始するときは、リスク評価設計の完全なセットとセキュリティ管理の明確なガイドラインを用意するか、承認されたサービスを通じてそのようなセキュリティ管理を使用する必要があります。 IDE に統合された自動静的コード ツールは、コードの作成時に開発者にチェックとガイダンスを提供します。自動ツールを使用して、コンパイル中にポリシー テンプレートに対するコードの違反をチェックすることもでき、コード レベルのセキュリティ問題を掘り下げることができます。

コードの実行フェーズとコンパイルフェーズにセキュリティを統合する手順

1. 統合開発環境と統合できる静的ソースコード検査ツールをインストールします。

2. オプションとして、開発者は独立したコーディングツールを使用して、コードを配信する前に自動コード検査を実行できます。

3. セキュリティおよび監査チームは、コードモジュールがコンプライアンス要件に準拠しているかどうかを抜き取りチェックし、自動または手動のコード検査を使用してコンパイル前にセキュリティリスクをチェックします。

4. コンパイルプロセス中に、自動静的コードスキャンを実行して、セキュリティの問題とポリシーへの準拠を見つけます。

5. ツールを使用して開発者のコ​​ーディングエラーを追跡し、説明的なフィードバックとそれがもたらすセキュリティリスクの理由を提供します。

これにより次のようなメリットが得られます:

1. よりクリーンな、またはバグの少ないコードを品質評価者に提出できます。

2. 時間の経過とともに、開発者は安全なコーディング能力を向上させることができます。

3. 再利用可能な戦略により、リスク分析の精度が向上します。

4. テスト段階で発見されるコーディングエラーや脆弱性が少なくなり、開発サイクルが短縮されます。

品質評価/テスト

アプリケーションをテストするための特定のセキュリティ ツールは、完全なアプリケーションを評価できるスタンドアロン ソリューションとサービスから、テストと検証を提供する完全に統合されたスイートまで多岐にわたります。教育から実装までの複数の段階でサポートされます。統合ソリューションは、反復可能な Web アプリケーション セキュリティ サイクルの成熟度を実証した企業に多段階のサポートを提供できます。統合スイートはプロセスの複数のポイントで実装でき、継続的な改善のための指標とフィードバックを提供します。

それでは、品質評価とテスト段階でセキュリティを統合し、セキュリティを向上させるにはどのような手順を実行する必要がありますか?

1. 特定のリソースで最も重要な問題を発見することに重点を置きます。

2. 既存の修復制御 (ファイアウォールや IPS など) を含むアプリケーション アーキテクチャ内でこれらのテスト結果を検証します。

3. セキュリティとビジネスのニーズに基づいて、発見された脆弱性に優先順位を付けます。

4. コード行またはそれらが依存する API、サービス、ライブラリなどの修復を提案します。

利点も明らかです: 1. アプリケーション開発者同士のコミュニケーションが向上します。 2. もっともらしさは低い。 3. 修理サイクルの短縮。

デプロイ/本番環境への導入

Web アプリケーションのセキュリティは、アプリケーションのデプロイメント段階で終了するわけではありません。 Web アプリケーションが運用開始されたら、データとサービスが確実に保護されるように追加のテストと監視を実装する必要があります。実際の Web アプリケーションの自動セキュリティ監視により、アプリケーションが期待どおりに実行され、リスクを引き起こす可能性のある情報が漏洩していないことが保証されます。監視は社内で行うことも、アプリケーションを 24 時間監視できる外部ベンダーに委託することもできます。

展開フェーズと実稼働フェーズでセキュリティを統合および改善する手順:

1. 誤用を監視します。その目的は、テストでのいわゆる「悪用できない脆弱性」が実稼働後に実際に悪用されないことを判断することです。

2. データが不正に使用、送信、保存されたすべての場所を見つけることを目的として、データ漏洩を監視します。

3. 導入前のリスク評価と本番後の暴露範囲を比較し、テストチームにフィードバックを提供します。

4. Web アプリケーション ファイアウォール、IPS、またはその他の修復措置を実装して、コードを修正する前に露出を軽減したり、新しいセキュリティ規制に準拠したりします。

メリットは以下のとおりです:

1. 正常に実装できるエクスプロイトの知識ベースが向上し、静的および動的テスト中のスキャン効率が向上します。

2. アプリケーションの不正使用を発見し、防止します。

3. 動的テストと運用環境でのアプリケーション制御 (Web アプリケーション ファイアウォールや IPS など) の統合を改善します。

4. コードを再度記述する前に、コンプライアンスのニーズを満たします。

5. フィードバックメカニズムを使用して、継続的な改善を達成します。

まとめ

Webアプリケーションのセキュリティを確保することは、必ずしも開発サイクルを延長することを意味するわけではありません。すべての開発者に対する適切な教育と明確で再現可能なビルド プロセスがあれば、組織は効率的かつ協力的な方法でセキュリティとリスクを開発プロセスに組み込むことができます。

Web アプリケーションの配信サイクルにセキュリティを組み込むには、人、プロセス、テクノロジーを統合する協力的なアプローチが必要です。 Web アプリケーションのセキュリティ ツールとスイートはプロセスの改善に役立ちますが、万能薬ではありません。最大限のメリットを得るには、開発サイクル全体を理解し、開発プロセスの複数の段階でサポートを提供できるツールを備えた Web アプリケーション セキュリティ ツール ベンダーを選択することを検討する必要があります。


以上がWeb アプリケーションのセキュリティを確保する方法を教えてくださいの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート