OWASP（Open Web Application Security Project）- Security by Design Principlesは、次の10つの原則から構成されます。
- 攻撃対象面積の最小化
- 安全なデフォルトの確立
- 最小特権の原則
- 防御深度の原則
- 安全に失敗する
- サービスを信頼しない
- 業務分離の原則
- セキュリティを隠蔽しない
- シンプルにセキュリティを維持する
- セキュリティ問題を正しく修正する
OWASPは、ソフトウェアセキュリティを改善することを目的とする世界的な組織で、開発者やセキュリティ専門家が安全なアプリケーションを構築するための貴重なリソースとツールを提供しています。彼らの主要な取り組みの1つであるSecurity by Design Principlesについて、この記事では、各原則について詳しく説明します。
- 攻撃対象面積の最小化（Minimize attack surface area）
- 安全なデフォルトの確立（Establish secure defaults）
- 最小特権の原則（Principle of Least privilege）
- 防御深度の原則（Principle of defense in depth）
- 安全に失敗する（Fail securely）
- サービスを信頼しない（Don’t trust services）
- 役割分離（Separation of duties）
- セキュリティに曖昧さを持たせない（Avoid security by obscurity）
- セキュリティを簡単に保つ（Keep security simple）
- セキュリティ上の問題を正しく修正する（Fix security issues correctly）
- まとめ
攻撃対象面積の最小化（Minimize attack surface area）
Security by Designの最初の原則は、攻撃対象面積を最小限に抑えることです。これは、攻撃者がアプリケーションに侵入できる方法を減らすことを意味します。攻撃対象面積を最小限に抑えることで、攻撃の成功確率を減らすことができます。
これを実現するために、アプリケーションに必要な機能のみを含めるようにし、脆弱性を導入する可能性のある不必要な機能やコードを削除します。さらに、ユーザーからの入力を適切に検証し、機密情報へのアクセスを制限する必要があります。
安全なデフォルトの確立（Establish secure defaults）
2番目の原則は、安全なデフォルトを確立することです。これは、最初からアプリケーションを安全な状態に設定することを意味します。安全なデフォルトを確立することで、一般的な攻撃からアプリケーションを保護することができます。
例えば、強力な暗号化アルゴリズムを使用し、パスワードを安全に保存する必要があります。また、安全な接続プロトコルを使用し、必要に応じてアクセスコントロールを設定する必要があります。
最小特権の原則（Principle of Least privilege）
3番目の原則は、最小特権の原則です。これは、アプリケーション内で必要最低限の権限を使用することを意味します。この原則に従うことで、攻撃者がシステム内で重要なアクションを実行することを防止することができます。
例えば、ユーザーが必要な権限以上のアクセスを持っていないことを確認する必要があります。また、アプリケーション内でユーザーアカウントを分離する必要があります。
防御深度の原則（Principle of defense in depth）
4番目の原則は、防御深度の原則です。これは、複数の防御策を使用して、アプリケーションを保護することを意味します。1つの防御策が失敗しても、他の防御策が攻撃を防止することができます。
例えば、ファイアウォール、アンチウイルスソフトウェア、侵入検知システムなど、複数の防御策を組み合わせて使用することが重要です。
安全に失敗する（Fail securely）
5番目の原則は、安全に失敗することです。これは、アプリケーションが失敗した場合でも、情報漏洩や攻撃を防止することを意味します。
例えば、アプリケーションがクラッシュした場合でも、重要な情報が漏洩しないようにする必要があります。また、エラーメッセージに適切な情報を含め、攻撃者に有用な情報を提供しないようにする必要があります。
サービスを信頼しない（Don’t trust services）
6番目の原則は、サービスを信頼しないことです。これは、外部のサービスが常に安全であるとは限らないことを意味します。外部のサービスが脆弱性を持っている場合、それらを使用することでアプリケーション自体が脆弱性を持つことになります。
例えば、外部のAPIを使用する場合は、そのAPIが信頼できるかどうかを慎重に検討する必要があります。
役割分離（Separation of duties）
7番目の原則は、役割分離です。これは、アプリケーション内の異なる機能に対して異なる権限を持つユーザーを設定することを意味します。これにより、攻撃者がシステムに侵入した場合でも、システム全体を制御することができなくなります。
例えば、開発者はプロダクションシステムにアクセスできる必要があるかもしれませんが、ユーザーアカウント管理などの機能にアクセスする必要はありません。
セキュリティに曖昧さを持たせない（Avoid security by obscurity）
8番目の原則は、セキュリティに曖昧さを持たせないことです。これは、セキュリティを犠牲にして機能を追加することを避けることを意味します。セキュリティに影響を与える可能性のあるすべての機能について、適切なセキュリティ検討を行う必要があります。
例えば、ユーザーがログインした後に、自動的にパスワードを保存する機能を追加する場合、セキュリティリスクがあることを認識しておく必要があります。
セキュリティを簡単に保つ（Keep security simple）
9番目の原則は、セキュリティを簡単に保つことです。セキュリティを複雑にすることは、ユーザーエクスペリエンスに悪影響を与えることがあります。セキュリティに関する決定を簡単に理解できるようにすることが重要です。
例えば、ユーザーに複雑なパスワードポリシーを課すことは、ユーザーがアカウントを作成することを躊躇させることがあります。代わりに、簡単なパスワードポリシーを使用し、ユーザーが簡単にアカウントを作成できるようにすることが望ましいです。
セキュリティ上の問題を正しく修正する（Fix security issues correctly）
10番目の原則は、セキュリティ上の問題を正しく修正することです。セキュリティ問題に対処する場合、問題を解決するだけでなく、その原因も解決する必要があります。修正を急いで行うことは、問題をより深刻なものに変えることがあります。安全な方法で修正を行うことが重要です。
例えば、脆弱性を修正する場合、修正の効果をテストするために、十分な時間を確保する必要があります。修正を急いで行い、問題がまだ残っている場合、それは攻撃者に利用される可能性があります。
まとめ
OWASPのSecurity by Design Principlesは、セキュリティをシステムの開発の初期段階から組み込むことに焦点を当てています。これらの原則に従うことで、システムにより高いレベルのセキュリティを実装することができます。開発者や企業は、これらの原則を遵守して、セキュリティを確保し、ユーザーや顧客のデータを保護することが重要です。
コメント