移行時に考慮すべきAWSセキュリティの10項目

クラウドデータストレージには従来のデータセンターにはない実用的なメリットが数多くありますが、移行にあたっては固有のセキュリティ上の考慮事項も多くあります。

AWSへの移行は、今後を見据えた進め方から始めましょう。クラウドデータストレージへ移行する企業は、データを保護するために情報セキュリティへの取り組みを見直す必要があります。移行時に適切なセキュリティ対策を整えておけば、将来のチームがアプリケーションや機能を安全かつ効率的に提供し、AWSでよくあるリスクを回避できます。一方、従来のセキュリティ対策に固執すると、チームの足かせとなり、将来の成功を妨げることになります。

移行を簡単かつ安全に進めるための重要なポイントをまとめたレポートSnyk Top 10: Security Strategies when Migrating to AWSを公開しました。この記事では、それぞれのポイントを簡単にご紹介します。

1. AppSecとCloudSecを一体的に捉える。

2. セキュリティチームをAppDevチームやDevOpsチームに組み込む。

3. SDLC全体にセキュリティを取り入れ、アプリケーション開発をモダナイズする。

4. セキュリティを考慮してクラウドアーキテクチャを設計する。

5. 開発者やクラウドエンジニアが安全に構築できる環境を整える。

6. 最初からInfrastructure as Codeを活用し、安全性を確保する。

7. デプロイパイプラインでクラウドセキュリティのガードレールを活用する。

8. Policy as Code（PaC）を基盤にクラウドセキュリティを構築する。

9. IDおよびアクセス管理（IAM）サービスを安全に利用する。

10. 重要なことを見極め、継続的に測定する。

1. AppSecとCloudSecを一体的に捉える

以前は、クラウド運用とアプリケーション開発を別々のレイヤーに分けることができました。しかし今では、アプリケーションセキュリティとインフラストラクチャセキュリティの境界はますます曖昧になっています。攻撃者は、スタック内のあらゆる場所にある脆弱性を容易に悪用できます。AppSecチームとCloudSecチームが別々のツールでアプリケーションのセキュリティリスクをスキャンしていると、複数のレイヤーにまたがる脆弱性や、あるレイヤーが別のレイヤーに影響する状況を見逃すおそれがあります。

AppSecとCloudSecのセキュリティをサイロ化させないようにしましょう。包括的なDevSecOpsのアプローチでは、リスクを発見して軽減するための一元化された統合プロセスを採用する必要があります。これにより、クラウド環境とソフトウェア開発の両方をより深く把握できるだけでなく、効率が向上し、組織全体でリスクの優先順位をより適切に判断できます。

2. セキュリティチームをAppDevチームやDevOpsチームに組み込む

サイロ化は、フルスタックセキュリティとアジャイル開発の両方を遅らせます。セキュリティを独立した機能として扱う従来のやり方では、新たなリスクが発生するたびにチームが作業を中断して対処しなければならず、多大な時間がかかることがあります。

その代わり、ソフトウェア開発ライフサイクルにセキュリティ対策と制御を組み込むことで、セキュリティリスクに早期に対処しましょう。DevSecOpsのアプローチでは、ソフトウェア開発ライフサイクル（SDLC）の可能な限り早い段階からセキュリティ目標を取り入れ、セキュリティに対する共同責任の文化を育みます。クラウドベースのシステムを設計・開発する際に、セキュリティチームが開発者やクラウドエンジニアと連携すれば、SDLCのあらゆる段階にセキュリティを組み込み、効率を最大化できます。

この共同責任を実現するには、開発者が使い慣れたプラットフォームに統合できる、開発者を第一に考えたツールが役立ちます。一元的な可視性とチーム間の円滑なコミュニケーションを実現するプラットフォームも、効果的なコラボレーションに欠かせません。

3. SDLC全体にセキュリティを取り入れ、アプリケーション開発をモダナイズする

AWSへの移行は、SDLC全体をエンドツーエンドで保護する体制へ移行する絶好の機会です。

アプリケーション開発プロセスの後半までセキュリティテストを行わないと、遅延につながる可能性があります。代わりにシフトレフトのアプローチを採用し、SDLCの早い段階からセキュリティを組み込むことで、開発のアジリティを維持し、クラウド技術によって新たに生じるリスクに対処しましょう。

すべてのプルリクエストに自動セキュリティチェックを導入し、新しいコード変更を本番環境に取り込む前に問題を特定しましょう。アプリケーションの構築とテストの過程でセキュリティ状態を確認できるため、セキュリティを全体的に把握しやすくなります。

4. セキュリティを考慮してクラウドアーキテクチャを設計する

攻撃者は、価値あるデータへのアクセスを得るために、アーキテクチャ上の弱点を悪用することがよくあります。攻撃者の視点で弱点を特定し、セキュリティ脅威の影響を最小限に抑えましょう。クラウドでよくある設定ミスを確認し、事前に回避してください。

セキュリティチームのAWSセキュリティアーキテクトとしてのスキルを強化しましょう。Cloud Security PodcastやAWSのトレーニングプログラムおよび認定資格などのリソースを活用してください。クラウドセキュリティアーキテクトの専任職を設け、安全なクラウドアーキテクチャの構築と管理を担ってもらうことも検討しましょう。

5. 開発者やクラウドエンジニアが安全に構築できる環境を整える

クラウドの設定ミスが発生した場合、機能を損なわずに修正するのに最適な立場にいるのは開発者です。多くの場合、デプロイ前にアプリケーションコードやInfrastructure as Code（IaC）テンプレート（AWS CloudFormation、AWS CDK、Terraformなど）を安全にできるのは、開発者だけです。

開発者に権限を与えるとは、アプリケーションのセキュリティに関する意思決定を行い、その責任を担えるようにすることです。この変革には、文化と業務の両面での変化が必要になることが多く、経営層からのメッセージ、教育、チーム間の可視性と透明性、適切なツールによる支援が欠かせません。開発者が自らコードの弱点を特定し、修正するために必要なものを揃えましょう。

6. 最初からInfrastructure as Codeを活用し、安全性を確保する

Infrastructure as Code（IaC）により、インフラストラクチャをコードとして扱えるようになります。もはやその保護はITチームだけの責任ではなく、開発者の責任でもあります。IaCを安全にする最善の方法は、コーディングのベストプラクティスに従い、アプリケーションコードと併せてチェックすることです。

IaCは、AWS環境を大規模に構築・管理するための、より効率的で一貫性のある方法です。また、デプロイ前にクラウドセキュリティをチェックできます。IaCのセキュリティチェックにより、クラウドの設定ミスを中央値で70%削減できるうえ、エンジニアリングの生産性とデプロイ速度も中央値で70%向上します。

AWSへの移行を始める段階で、安全なIaCを実現するためのプロセスと手順を定めておけば、移行を明確かつ迅速、効率的に進められます。Amazon Web ServicesはネイティブのIaCソリューションとしてAWS CloudFormationを提供しており、Terraformのような独立した選択肢も広く利用されています。

7. デプロイパイプラインでクラウドセキュリティのガードレールを活用する

セキュリティをシフトレフトすると、セキュリティ上の問題を検出するために環境を継続的に監視する必要があります。デプロイ前に設定ミスを防ぐため、CI/CDでセキュリティチェックを自動化しましょう。IaCを使えば、AWSにデプロイするアプリケーション向けに構築されるインフラストラクチャへ、クラウドセキュリティチェックを追加できます。

クラウドセキュリティにDevSecOpsのアプローチを取り入れると、問題が発生したときにエンジニアは自動フィードバックを受け取り、迅速かつ安全に修正するための明確なガイダンスを得られます。IaCを活用すれば、エンジニアが同じような設定ミスを繰り返しデプロイすることも防げます。

8. Policy as Codeを基盤にクラウドセキュリティを構築する

手作業によるコンプライアンスレビューは時間がかかり、規模の拡大も困難です。Policy as Code（PaC）ツールは、ポリシーをコード化して適用することで、このプロセスを自動化します。迅速かつ効率的になるだけでなく、人的ミスの可能性を排除できるため、信頼性と一貫性も高まります。

PaCを使って単一の信頼できるポリシーを作成し、開発者、セキュリティ、DevOps、コンプライアンスの各チームが共通の基準として活用できるようにしましょう。ポリシーを自動化すれば、セキュリティチームは人員を増やすことなく取り組みを拡大できます。

9. IDおよびアクセス管理サービスを安全に利用する

IDおよびアクセス管理（IAM）の目的はユーザー権限の管理だけに見えるかもしれませんが、クラウドベースのネットワーク全体を把握するうえでも最適な手段です。過剰に許可されたIAM設定は、攻撃者にクラウドのコントロールプレーンへの侵入を許す入口になります。

安全なIAM設定は、クラウドセキュリティアーキテクチャの中核に据えるべきです。IAM設定に弱点がないか継続的に評価し、最小権限の原則に基づいて構築されたIAMサービスをエンジニアが安全に利用できるよう支援しましょう。クラウドセキュリティの専門家を置けば、IAMの適切な設定と管理を徹底できます。

さらに、強固なパスワードや多要素認証（MFA）の重要性について、ユーザー一人ひとりにセキュリティ意識向上トレーニングを実施する必要があります。

10. 重要なことを見極め、継続的に測定する

AWSセキュリティへの取り組みが適切に機能していることを確認するには、指標が欠かせません。クラウドセキュリティプログラムの有効性を測定することが重要です。AWSセキュリティを適切に実践しているチームは、取り組みを業務に定着させ、重要な指標を規律をもって測定しています。

セキュリティ態勢の現状を把握し、具体的な数値で示せるようにしましょう。従来のデプロイモデルとは異なる数値が必要になる場合もあります。CI/CDのデプロイモデルでは、一定レベルの脆弱性は許容され、想定されるものです。エンドツーエンドのセキュリティアプローチによって、重大な脆弱性と重大ではない脆弱性を見分け、最も重要なものに優先的に対処できます。リスクの低減だけでなく、開発者やDevOpsチームが脆弱性を修正する効率の向上も測定し、進捗を示しましょう。

組織の優先事項に応じて、修復までの時間、未解決の重大度「高」の脆弱性の割合、リスクを受容した脆弱性の数、重大度「低」の脆弱性の割合などを指標として検討できます。どの指標も一度測れば終わりではありません。継続的に改善し続けることが目標です。