AWS in 30のまとめ

先月、Lead Partner Solutions ArchitectのDavid Schottが、Amazon Web Services（AWS）とSnykを連携させ、開発とインフラのあらゆる段階で脆弱性を特定する方法をデモで紹介しました。

Davidは、クラウドでのアジャイル開発には、従来のITセキュリティ手法をそのまま使うのとは異なるアプローチが必要な理由を解説しました。続いて、SnykのAWSクラウドセキュリティツールで一般的な脆弱性をリアルタイムに検出し、対処する様子を紹介しました。プレゼンテーションの内容と、主なポイントを見ていきましょう。

モダンアプリケーション：新たなリスクプロファイル

今日のクラウド環境が、ビジネスに数え切れないほどのメリットと機会をもたらしていることは明らかです。クラウド運用とInfrastructure as Code（IaC）の柔軟性により、開発はかつてないほどアジャイルになっています。しかし、クラウドサービスのこうした進化とともに、新たなリスク環境も生まれています。

ITからアプリケーションサービスへ

クラウド開発の手法が登場する前、開発者はウォーターフォール型の開発手法に従っていました。コードを「壁の向こうへ投げ」、後になって発生するリスクの大部分をセキュリティ担当者に任せるのが一般的でした。開発者はアプリケーションのコードやオープンソースライブラリには責任を持つ一方、セキュリティのより大きな部分はITセキュリティチームが担っていました。ITアプリケーション、サーバー、VM、ネットワーク、vSphere、ハードウェアなどのリソースに関するリスクの軽減に取り組んでいたのです。

今日、開発者はコードをホストし実行するクラウドサービスに対して、より大きな責任を担うようになっています。コンテナ、IaC、Kubernetesなどのオーケストレーションツールがその例です。責任の所在が変わったことで、ITセキュリティだけがクラウドインフラの保護を担うことはできなくなりました。代わりに、開発者を中心に据えたアプリケーションセキュリティのアプローチが必要です。

「現在、開発者はクラウドやコンテナ、Kubernetesを活用しています。これにより、これまで以上のスピードで開発を進めています。同時に、こうしたさまざまな領域に対する責任も増しています。開発者がすべての分野に精通しているわけではないため、セキュリティの脆弱性が入り込むのは避けられません。」

モダンアプリは氷山のようなもの

クラウドサービス（AWSなど）でホストされているモダンアプリケーションを詳しく見ると、氷山のように幾重にも層をなしていることがわかります。1行のコードが、オープンソースライブラリ、コンテナ、Infrastructure as Codeからなるエコシステム全体を表していることもあります。さらに、それぞれのコンポーネントの依存関係にも依存関係があるため、構造はどこまでも深く続きます。今日のアプリケーションは相互につながり合っているため、クラウドセキュリティを把握し続けるのは容易ではありません。

DevSecOpsが果たす役割

この依存関係という「氷山」に潜むリスクを検出して軽減するには、開発のあらゆる段階にセキュリティ対策を組み込むのが最善です（DevSecOpsのアプローチ）。適切なツールを、適切なタイミングでプロセスに取り入れることが重要です。たとえば、開発チームがコードの静的解析で検出できる脆弱性をできるだけ早く把握できれば、コードを書いた直後に問題に対処できます。一方、Kubernetesなどのオーケストレーションエンジンに関連するランタイムセキュリティ制御を導入できるのは、プロセスのずっと後の段階です。そのため、プロセスの1段階にセキュリティツールを導入するだけでは不十分です。開発チームには、アプリケーションのあらゆる段階とレイヤーをカバーするセキュリティが必要です。

あらゆる段階でAWSと連携するSnyk

ここまで見てきたように、ほとんどのモダンアプリケーションの裏側では、さまざまな処理が行われています。開発者は、アプリケーションコードだけでなく、それを支えるオープンソースライブラリ、コンテナ、クラウドインフラなど、アプリケーションのあらゆる領域で脆弱性を検出し、対処する方法を知っておくことが重要です。

Snykはこの課題のあらゆる要素に対応するツールを開発し、クラウドサービスとの連携を実現しています。デモでは、Davidが「氷山の各層」に対応するAWSクラウドセキュリティツールをSnykがどのように提供するかを紹介しました。

AWS CodePipeline（IDE）

Snykを使えば、開発者はAWS CodePipeline.にセキュリティチェックを組み込めます。Snykはパイプラインの「セキュリティゲート」として機能し、脆弱なコードが開発ライフサイクルの次の段階へ進むのを防ぎます。さらに、サードパーティ製およびオープンソースの脆弱性をリアルタイムで確認できる「ライブ」ビューを、開発者とセキュリティチームに提供します。このリアルタイムのフィードバックにより、定期的な再スキャンを待つ時間が不要になります。

Snykの「monitor」機能は、スキャン結果をSnyk UIにも送信し、詳細な分析、継続的な監視、再スキャンに利用できます。これにより、CI/CDでソフトウェアを再ビルドすることなく、Snyk UIで新たな脆弱性を確認できます。

SnykとCodePipelineの連携も簡単に設定できます。既存のSnykアカウントで認証するか、新しいアカウントを作成することで、数分でSnykをCodePipelineに統合できます。統合後は、Snykを使って新しいパイプラインを作成することも、既存のパイプラインにセキュリティ機能をステージとして追加することもできます。

Amazon ECR（コンテナレジストリ）

SnykプラットフォームはAmazon ECRとも連携できます。実際、AWSとのパートナーシップの一環として、Snyk Vulnerability DatabaseはすでにAmazon Inspectorに組み込まれています。Snykの機能により、Amazon Inspectorはコンテナイメージ、Amazon EC2インスタンス、AMIをスキャンし、アプリケーションの脆弱性を検出できます。

Amazon Inspectorにはすでに組み込まれていますが、Snyk Securityを利用すれば、コンテナレジストリ内の脆弱性についてさらに詳しい情報を得られます。SnykプラットフォームはAmazon ECRを継続的にスキャンし、コンテナイメージとベースイメージ内の脆弱性を検出します。リスクの低いベースイメージへの変更を推奨してリスクの軽減を支援し、ソースコードに変更を加えるプルリクエストを作成することもできます。

Amazon EKS（Kubernetes環境）

Snykはランタイム環境との連携にも対応しています。SnykのAWSクラウドセキュリティツールはAmazon EKSと連携し、コンテナの実行中に発生するセキュリティ上の問題を特定します。ECRとの連携と同様に、ベースイメージのアップグレードを推奨するほか、Kubernetes上でコンテナがどの程度安全に実行されているかについて、詳細な情報を提供します。

AWS CloudTrail Lake

デモの中でDavidは、開発者やセキュリティの専門家がセキュリティ脆弱性（CVE）を無視するケースを紹介しました。無視操作、ロールやメンバーシップの変更、設定変更などのユーザーアクションは、すべてSnyk Audit Logsに記録されます。Snykはお客様が監査ログにアクセスするためのAPIを提供していますが、いくつか制限があります。たとえば、監査ログは90日間保存された後、削除されます。この問題を解決するため、SnykはAWS CloudTrail Lakeと連携し、SnykプラットフォームからAWS環境へ監査ログをすばやく簡単に転送できるようにしています。AWS CloudTrail LakeではSQLを使って監査ログを検索でき、最長7年間、期間を設定してログを保持できます。

AWS Well-Architected

Snykのレポート機能では、さまざまな切り口でデータを分析できます。たとえば、重大度が「Critical」または「High」で、自動修正が可能なセキュリティ上の問題だけに絞り込めば、対処しやすい問題のリストを作成できます。「Issues Summary」ページでは、新たに発見された問題と修正済みの問題の推移や、平均修復時間（MTTR）などを確認できます。さらに、これらの傾向を個々のプロジェクトやチームごとに掘り下げることも可能です。Snyk Cloudでは、クラウドの設定ミスがHIPAA、SOC2、PCI-DSSなどのコンプライアンス基準にどのように対応するかを確認できます。Snykは、セキュリティや信頼性など6つの柱に重点を置くAWS Well-Architected Frameworkにも対応しています。数分でAWS環境をスキャンしてベストプラクティスに沿っていない箇所を特定し、問題に対処してAWSアーキテクチャを改善できます。

Snykで実現するAWSセキュリティ

AWSクラウドセキュリティツールの動作をご覧になりたい方は、David SchottによるAWS in 30 Recapのプレゼンテーション全編をご確認ください。アプリケーションの表面下に潜んでいる可能性のあるよくあるAWSの設定ミスについてもご紹介します。