テクノロジーは、ビジネスの運営方法から生活様式に至るまで、あらゆるものを変革しました。しかし、その利便性には新たな脅威が伴います。Target、Facebook、Equifaxといった企業で発生した大規模なセキュリティ侵害は、誰もその脅威から逃れられないことを改めて認識させました。テクノロジーリーダーとして、私たちには、デジタルアプリケーションとエコシステムのセキュリティ確保を誰もが責任を持つ文化を築く責任があります。
新しいアプローチ：設計によるセキュリティ
安全なアプリケーションの作成、構築、展開におけるアプローチの一つに、セキュリティ・バイ・デザイン（SbD）があります。2015年にAmazonホワイトペーパーが公開されて以来、クラウド業界で大きな話題となったSbDは、現在もAmazonが推奨するフレームワークであり、セキュリティを最初から体系的に構築するためのものです。SbDは、セキュリティ設計を体系化し、セキュリティ管理を自動化し、監査を効率化するセキュリティ保証アプローチです。このフレームワークは、アプリケーションのセキュリティ確保を4つのステップに分解します。
要件を把握する
ポリシーの概要を策定し、管理策を文書化します。適用するセキュリティルールを決定します。エコシステム内の外部サービスプロバイダーから継承するセキュリティ管理策と、自社で管理するセキュリティ管理策を把握します。
文書化された要件を満たす安全な環境を構築する
アプリケーションをサポートするインフラストラクチャの定義を開始するときは、セキュリティ要件を構成変数として参照し、各コンポーネントに書き留めます。
参照: 採用キット: データサイエンティスト (TechRepublic Premium)
例えば、アプリケーションで保存データの暗号化が必要な場合は、すべてのデータストアに「encrypted = true」タグを付けます。すべての認証アクティビティをログに記録する必要がある場合は、認証コンポーネントに「log = true」タグを付けます。これらのタグは、セキュリティを常に念頭に置いておくことを可能にし、後でテンプレート化すべき内容を判断するのに役立ちます。
ポリシー、自動化、テンプレートを通じて強制する
セキュリティ管理の内容と適用場所が明確になったら、人為的なミスは絶対に避けたいものです。そこでテンプレートが役立ちます。インフラストラクチャをコードとして自動化することで、システム自体が、定義したセキュリティルールに違反する環境を誰かが作成するのを防止してくれるので、安心です。どんなに些細な設定に見えても、管理者がクラウドやオンプレミスでマシンを手動で設定するのは避けたいものです。こうした変更を行うためのスクリプトを作成すれば、その費用は何千倍にも跳ね上がります。
定期的な検証活動を実行する
セキュリティ・バイ・デザイン・フレームワークの最後のステップは、セキュリティ対策の定義、スケジュール設定、そして定期的な検証です。これもほとんどの場合、定期的だけでなく継続的に自動化できます。重要なのは、常にコンプライアンスに準拠したシステムを構築し、その結果として常に監査に対応できる状態を維持することです。
SbD の投資収益率はどのくらいですか?
SbD アプローチは、適切に実行されると、数多くの具体的なメリットをもたらします。
- 権限のないユーザーが上書きできない機能を強制する
- 信頼性の高いコントロール操作
- 継続的かつリアルタイムの監査
- ガバナンスポリシーの技術的なスクリプト
さらに、オンプレミスでもクラウドでも、セキュリティ ポリシーが次のベクトルに対応していることを確認してください。
- ネットワークセキュリティ
- 在庫と構成の管理
- データ暗号化
- アクセス制御
- 監視とログ記録
主要な脅威に対する認識を維持する
実際のアプリケーション開発においては、OWASP Top 10 にご留意ください。これは、開発者とWebアプリケーションセキュリティに関する標準的な意識啓発文書です。Webアプリケーションにとって最も重大なセキュリティリスクに関する幅広いコンセンサスを示しています。時間の経過とともに変化しますが、以下に2022年版の脅威トップ10をまとめました。
- アクセス制御の不備
- 暗号の失敗
- 注射
- 安全でない設計
- セキュリティの誤った構成
- 脆弱で古いコンポーネント
- 識別と認証の失敗
- ソフトウェアとデータの整合性の障害
- セキュリティログと監視の失敗
- サーバーサイドリクエストフォージェリ
開発者がこれらの脅威（SbDプロセスのステップ1）を理解し、適切な制御を特定して実装（ステップ2および3）できるようにすることは重要ですが、開発プロセス中および開発プロセス後に検証活動（ステップ4）を実施することも同様に重要です。この検証を支援する商用ツールやオープンソースツールは数多くあります。
OWASPプロジェクトはこれらのツールの最新リストを常に更新しており、いくつかのオープンソースプロジェクトを直接管理しています。これらのツールは主に特定のテクノロジーと、そのテクノロジーに特有の攻撃を標的としていることがわかります。
アカウントレベルのベストプラクティス
セキュリティに対する最大のリスクであるユーザーを軽減しなければ、組織は真のセキュリティを確保できません。ここでアカウントのベストプラクティスが重要になります。アカウントのベストプラクティスを適用することで、組織はユーザーがシステム全体のセキュリティを不用意に侵害することを防ぐことができます。組織として、アカウント管理に関するセキュリティのベストプラクティスを遵守するようにしてください。
- すべてのリソースに強力なパスワードを適用する
- アカウントレベルでグループメールエイリアスを使用する
- MFAを有効にする
- 日常的なアクセスにはルート権限を使わない
- アカウントレベルのアクセスキーを削除する
- ログを有効にする
コンプライアンスと規制要件を忘れない
業界や地域によっては、追加のセキュリティ管理策への準拠が求められる場合があります。一般的な例としては、決済に関するPCI DSSや医療記録に関するHIPAAなどが挙げられます。事前に十分な調査を行うことが重要です。これらの追加のセキュリティ要件のいずれかに該当する場合は、違反すると高額な罰金が科せられることが多いため、必要な管理策を専門とするセキュリティコンサルタントに相談することをお勧めします。
組織はサイバー攻撃の標的となる一方で、被害者は個人であることを忘れないでください。彼らは顧客であり、従業員であり、あなたとあなたのテクノロジーに信頼を寄せている生身の人間です。だからこそ、組織は最初からアプリケーションのセキュリティ対策に力を入れることが最も重要です。
今日の急速に変化するデジタル環境では、事後対応型のセキュリティ対策では効果を発揮しません。賢明なCIOは、セキュリティに関する議論を左翼へと導き、全社を巻き込み、ソフトウェア開発ライフサイクルのあらゆる段階にベストプラクティスを組み込むなど、積極的なアプローチを採用しています。
