AWS Startup ブログ

【開催報告&資料公開】Startup.fm 新春特別企画 – AWS セキュリティワークショップ

こんにちは！Startup Solutions Architect のじゃが（Twitter: @jagaimogmog）です。

2/25 にStartup.fm 新春特別企画 – AWS セキュリティワークショップを開催しました。「Startup.fm」はスタートアップ出身の AWS エンジニアが、1時間ほどテーマを決めて AWS のサービスや最新事例をご紹介するとともに、テーマに関連した視聴者の相談を回答していくイベントです。
今回は新春特別企画として、3時間のセキュリティワークショップを実施しました。本記事では録画・リンク集の共有、そして実際に頂いた質問と回答をご紹介します。

概要

スタートアップではセキュリティ投資よりも開発スピードが重視されることが多いかと思います。しかし、アーリーなスタートアップでも最低限のセキュリティ対策を実施いただくことで憂いなく開発に集中できます。また、スタートアップが成長するにつれて社会的責任は大きくなり、取引先に大企業が増えることでコンプライアンス対応が迫られるケースも増えてきます。普段スタートアップの技術支援をする中で、セキュリティレベルの向上が重要なのは理解しているが、どうしたら良いかわからないというスタートアップの開発者様とお話しすることは多いです。そこで、クラウドの設計原則・ベストプラクティスをまとめたAWS Well-Architected Frameworkを元に、セキュリティに特化したワークショップをスタートアップのお客様向けに開催いたしました！

ワークショップを通じて、実際にお客様のシステム環境が、セキュリティ面のベストプラクティスに沿っているか、沿っていない場合にはどのようなセキュリティリスクが存在するかを把握することができます。更には、改善方法についてもご確認いただくことが可能になります。

自社システムのセキュリティ状況を確認したい方や、これからセキュリティ対応を本格的に始められる方は、セキュリティインシデント発生のリスクを抑えるために、ぜひ本ワークショップの内容をご活用いただければと思います。

以下のアジェンダで実施いたしました。

  1. AWS Well-Architected Frameworkとは？
  2. Well-Architected Tool の解説
  3. セキュリティの柱詳細解説＆参加各社様でWell-Architected Toolにて入力
  4. Security Specialist Solutions Architect 交えた Q&A

ワークショップ動画

ワークショップ中に参照したリンクについては本記事末尾に記載があります。録画と合わせてご利用ください。

Q&A

Q) AWS SSOによってマネコンへのサインインは一元管理できると思いますが、一方で、開発者のローカルでcredentialを利用する要件があります。CLIなどでSSOを利用するためのAWS公式のソリューションはありますか？

A) AWS CLI v2 では AWS SSO を用いてIAMの権限を利用することが可能です。詳しいセットアップ方法などは以下のドキュメントをご参照ください。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-sso.html

Q) Organizationsを使っておらず本番環境と開発環境はシングルアカウントでリージョンで分ける管理をしています。マルチアカウント管理に移行したいのですが、SAの方に移行をサポートいただくことは可能でしょうか？

A) はい、もちろんです！普段ご連絡いただいている営業担当、あるいは Online Ask An Expert までお気軽にお問い合わせください。

Q) AWS SSOをぜひ導入したいのですが、参考になりそうな記事や資料等はありますでしょうか？AWS, GSuite, Slackが最低限サインインしたいアカウントになります。AWS は AWS Organizations に紐づく複数のアカウントがあります

A) BlackBeltオンラインセミナー「AWSアカウント シングルサインオンの設計と運用」の資料をご確認ください。

Q) DDoS対策としてCloudFront導入によるエンドポイントの分散というソリューションがあると思いますが、キャッシュのチューニングが不安なのでキャッシュしない形で導入したとしてもDDoSへの対応にはならないでしょうか？

A) AWS上のDDoS攻撃のほとんどはボリューム攻撃です。ボリューム攻撃は、 Amazon CloudFront、Elastic Load Balancing (ELB)、Amazon EC2 の Elastic IP アドレスなどに対してDDoS緩和を行うAWS Shield をお使いいただくことで、防ぐことが可能です。AWS Shield Standard は追加料金なしで全てのAWSアカウントで有効化されています。より高度なDDoS対策が必要な場合は AWS Shield Advancedの利用をご検討ください。
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/shield-chapter.html

Q) セキュリティチェックでよく「改ざん検知」の対策を求められますが、よい対策やベストなものがなかなかありません。なにかいいベストプラクティスはありますか。（EC2インスタンス、ECSコンテナなど）

A) EC2の改ざん検知=AMIの改ざん検知と仮定してお話しさせていただきます。外部のユーザーが作成したAMIを利用する場合は、3rd Partyのベンダーが作成するコミュニティAMIでなく、認証された販売主が提供するAWS MarketplaceのAMIをなるべく利用するようにしましょう。加えて、AWS MarketplaceのAMIはAMI Security Policy に則る必要があり、例えば「ルートユーザーログインが無効化されている」ことが保証されます。よりセキュアなMarketpace AMIのご利用をお勧めします。

コンテナイメージでの改ざん検知に関しては、Docker Content Trust のような署名の仕組みがあります。一方、現状対応が Docker CLI のみで Kubernetes や Amazon Elastic Container Service(ECS) といったオーケストレーターで署名を検証できないといった課題もあります。コンテナにおける改ざん検知についてより詳しいディスカッションが必要な場合は、AWSの担当者までお問い合わせください。

AWS Lambdaでは AWS Signer を利用してコード署名の検証が可能です。詳しくは以下のブログをご参照ください。

https://aws.amazon.com/jp/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/

また、これらのサービス上で動作するコードやライブラリの検証については、従来のコード署名ツールをお使いいただくことが可能です。

Q) CloudTrailのS3ログを、誰も削除・更新出来ないようにする方法には、どんなものがありますか？

A) 権限の観点では、AWS Organizations の Service Control Policy (SCP) を用いて、該当するAWSアカウントでの S3バケット内のデータの削除・更新ができないように権限を縛ることができます。SCPの縛りはIAMよりも強いので、仮にIAM UserでS3バケット内のデータの削除が許可されていたとしても、SCPにより削除ができなくなります。AWS Organizationsを使用されていない場合は、AWS IAMや、IAMのPermission Boundaryを利用して権限を縛ることが可能です。

S3側の機能としては、S3 オブジェクトロックをご利用いただくことで、指定した期間内のデータ削除・更新を無効化することが可能です。

また、CloudTrailログファイルの整合性の検証機能をお使いいただくことで、ログファイルが変更・削除されなかったか検証いただくことも可能です。

Q) ユーザーのIAMをSSOに切り替えることをビギナーがやったとして初回どの程度の時間がかかるものなのでしょうか？規模はスタートアップな10人程度を想定してます。

A) ステップとしては大まかに 1. 現状の権限管理の棚卸し 2. 棚卸しした権限をSSOで作成・マッピング 3. ID基盤(IdP)と接続、があります。1. は人数規模や必要な権限管理の複雑性によってかかる時間が変わってきます。3.はすでにActive Directoryなどで管理されている場合は時間はかかりませんが、一からID基盤を作ろうと思うと時間がかかるかもしれません。一方で、AWS SSOでユーザー管理をすることもできますので、既存のID基盤がない場合はそちらの利用を検討されてもよいでしょう。

まとめ

本記事では Startup.fm 新春特別企画 – AWS セキュリティワークショップ の動画、Q&A、そして参照したリンク集(付録)を共有させていただきました。最後に、動画の最後にお伝えした、ワークショップ後に最低限実施していただきたい3つのことをご紹介して終わりたいと思います。

  1. AWSアカウントのルートユーザーにMFAをつけた上で普段使いをやめ、代わりにIAM UserやAWS SSOを利用する
    1. https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_root-user.html#id_root-user_manage_mfa
  2. Amazon GuardDuty を 有効化し、セキュリティインシデントに気づけるようにする
    1. https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_settingup.html
  3. AWS CloudTrailの証跡機能(S3へのエクスポート)を有効化し、AWSに対するAPI操作ログを永続化する
    1. https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html

これだけ実施しておけば安全というものではございません。手始めにこの3つの対策からはじめていただき、少しずつ自社のセキュリティレベルを高めるきっかけとしていただけますと幸いです。

 

付録: ワークショップで参照したリンク集

本セクションでは、先述のワークショップ動画中に参照したリンクを掲載しています。ワークショップ動画と合わせてご利用ください。

SEC 1. ワークロードを安全に運用するには、どうすればよいですか?

アカウントを使用してワークロードを分ける

AWS アカウントのセキュリティを確保する

セキュリティ脅威に関する最新情報を入手する

セキュリティのレコメンデーションに関する更新情報を入手する

パイプラインのセキュリティコントロールのテストと検証を自動化する

新しいセキュリティサービスと機能を定期的に評価および実装する

SEC 2. ユーザー ID とマシン ID はどのように管理したらよいでしょうか?

強力なサインインメカニズムを使用する

一時的な認証情報を使用する

シークレットを安全に保存して使用する

一元化された ID プロバイダーを利用する

定期的に認証情報を監査およびローテーションする

ユーザーグループと属性を活用する

SEC 3. 人とマシンのアクセス許可はどのように管理すればよいでしょうか?

緊急アクセスのプロセスを確立する

アクセス許可を継続的に削減する

組織のアクセス許可ガードレールを定義する

パブリックおよびクロスアカウントアクセスの分析

リソースを安全に共有する

SEC 4. セキュリティイベントをどのように検出し、調査していますか？

サービスとアプリケーションのログ記録を設定する

ログ、結果、メトリクスを一元的に分析する

イベントへの応答を自動化する

実用的なセキュリティイベントを実装する

SEC 5. ネットワークリソースをどのように保護しますか?

ネットワークレイヤーを作成する

すべてのレイヤーでトラフィックをコントロールする

ネットワーク保護を自動化する

検査および保護を実装する

SEC 6. コンピューティングリソースをどのように保護していますか?

脆弱性管理を実行する

コンピューティング保護を自動化する

ユーザーが遠距離でアクションを実行できるようにする

ソフトウェアの整合性を検証する

SEC 7. どのようにデータを分類していますか?

ワークロード内のデータを特定する

識別および分類を自動化する

SEC 8. 保管時のデータをどのように保護していますか?

安全なキー管理を実装する

保管中に暗号化を適用する

保管時のデータの保護を自動化する

アクセスコントロールを適用する

SEC 9. 転送時のデータをどのように保護していますか?

安全な鍵および証明書管理を実装する

伝送中に暗号化を適用する

意図しないデータアクセスの検出を自動化する

ネットワーク通信を認証する

SEC 10. インシデントの予測、対応、復旧はどのように行いますか?

インシデント管理計画を作成する

ツールを事前にデプロイする

Special Thanks to Yoshitaka Haribara and Hayato Kiriyama for Review.