AWSとGCPを比較しながら体系的に整理する必要性
代表的なクラウドサービスであるAWSとGCPですがどちらもサービスが広大すぎて個別全て理解するのは骨が折れますし、だからと言ってわかる人間を一同に集めてはなさせれば複雑骨折します。
結局要するにどう言う位置付けでどう役に立つサービスなのかを体系的に整理された情報が有用であろうとまとめてみることにしました。
AWSとGCPではとにかく用語の違いが激しく、例えば一時的な IPのことをAWSでは「パブリック IP」といいGCPでは「エフェメラル IP」など枚挙にいとまがないのですがそこは本質ではないので、サービスを選定する側の立場として重要視する内容の対比ができるように情報を整理することとしました。
セキュリティサービスを活かすため最低限やっておかなければならないこと
rootユーザは使用しない。
rootユーザは利用しない。かつ、MFA(多要素認証)が基本です。
クレデンシャルのアクセス管理
ハッカーがまず狙うのはクレデンシャルです。SSRFを利用したクレデンシャルアクセスは有名ですが、
意図しない公開情報
以下のURLパターンでアクセスしていくだけでS3バケット内にアクセスできることがあります。
http://s3.amazonaws.com/(バケット名)（バケット名が前の方にあるURLは2019年９月以降使えません。）
AWS CLIを利用するのも簡単で「s3://(バケット名)」とすればアクセスできます。
aws s3 ls s3://(バケット名) -no-sign-request –region (リージョン名)
それでは本題に入りましょう。
アクセス権限管理AWS:AWS IAM/GCP:Cloud IAM
IAMはIdentity and Access Managementの略で識別に基づくアクセスの許可、不許可を管理します。
監査の観点でも「どのユーザ」が「どのリソース」に対して「いつ」「どんなアクセス」を行ったかが監査証跡として残すことができます。
どちらもポリシーとロールという概念がありますが両者で概念に差異があるので注意して理解しましょう。
SSH鍵はAWSの場合、新しいジョインがあるたびに既存のキーペアを共有する必要がありますが、GCPの場合、
メタデータに追加したユーザと対になるユーザと公開鍵がインスタンス作成時に自動で設定されるため不要です。
AWS:AWS IAM
AWSのどのリソースに対してどのような操作を許可するかを記述した単位であり、
ユーザやグループ、さらにはロール(役割)にアタッチできます。
そしてEC2やRDS、S3といったエンティティにロール(役割)を持たせることができます。
ポリシーの書き方
JSON形式で以下の４つのセクションを設定します。
Effect：Allow/Deny(明示されない場合はDeny)
Action：サービス名：アクションの形式で書く 例）s3:Get
Resource：ARNで記述
Condition：有効になる場合の条件
アクセスキーを公開しない。
ありえないとお思いでしょうがGitなどで公開する人があまりに多いためAWS側でもスキャンするようになりましたが、攻撃者もスキャンしているため公開していないか確認することを進めます。公開はしていなくともUberなどもクレデンシャルをとられさらにアクセスキーを奪取されました。
ユーザーの AWS 認証情報であるAWS Access Key ID および AWS Secret Access KeyはIAMユーザに紐づきます。
公開も気をつけなければなりませんが提供してしまわないようにキーペアをダウンロード（CSV形式）できるのですがトップクラスに機微な情報です。
公式にも「mazon のスタッフまたは関係者がこの情報を尋ねることは決してありません。」と明記されるように、AWSのサポートを装ってソーシャルエンジアリングにより盗み出される危険性があるため、教育訓練（Awareness Training）により対策すべきです。
一時許可を発行する場合にはAWS STS(Security Token Service)により、既存のID管理の仕組みを利用して一時的な認証情報を発行してアクセス制御を行うことができます。
GCP:Cloud IAM
「どのメンバー」が「どのリソース」に対して「どのようなアクセス権」を持つかを定義します。
ロールがあるリソースに対するアクセス権(Permission)を取りまとめたものでであるのは同じなのですが、
ポリシーは「メンバーとロールを合わせたもの」として定義されるためポリシーの概念が異なります。
ポリシーの書き方
メンバーuserid@gmail.comが権限compute.instances.deleteにバインドされるポリシーなどといったバインディングリストとなります。
ロールは個々のユーザーではなく、Googleグループに付与します。これにより個々のメンバーに変更とIAMポリシーの変更を切り離すことができます。
サービス アカウント キー
GCPが自主的に探しているような記事は確認できませんでした(もしやっていたら教えてください)が、公開がダメなことには
ネットワークアクセス管理 AWS:VPC Flow Logs/アクセス制御リスト（ACL）GCP:VPC Flow Logs/アクセス制御リスト（ACL）
ネットワークに関してはAWSではvpc作成時にあらかじめCIDRを設定が必要だが、GCPでは不要である点と、Network ACLがAWSには存在するが、GCPには存在しない点が大きく異なります。
AWS:VPC Flow Logs/アクセス制御リスト（ACL）/セキュリティグループ
VPC Flow Logs
VPC Flow LogsはVPCを選択しActionsのリストダウンからから[Create Flow Log]を選択、IAM Roleを設定して[Create Flow Log]を押下するだけで設定できます。
VPC Flow LogsはAmazon DNSに対して生成されるトラフィック、インスタンスmetaデータ（169.254.169.254）へのトラフィック
DHCPトラフィックは記録されません。
アクセス制御リスト（ACL）
Network ACLをサブネット単位で設定できるので、サイバー攻撃などに迅速に対処する場合などに利用できると考えられます。
セキュリティグループ
GCP:VPC Flow Logs/アクセス制御リスト（ACL）
VPC Flow Logs
VPC Flow LogsはGCPにも存在します。Pub/Sub 経由でAPIを利用することでSIEMと連携が可能です。
Loggingでのログの保持期間は30日間となっているため転送を前提とします。
アクセス制御リスト（ACL）
アクセス制御リスト（ACL）は存在しますが、Cloud Identity ＆ Access Management（Cloud IAM）の方を使用することが公式でも推奨されています。
gsutil、JSON API、XML API のいずれかを使用しACLを適用します。
DoS対策 AWS:AWS Sjield/GCP:Cloud Armor
前提として負荷分散を行うサービスの違いに触れる必要があります。AWSではElastic Load Balancingと呼ばれ、GCPではCloud Load Balancingと呼ばれていますが同じ負荷分散のサービスと考えてください。
異なる点はサポートされているプロトコルはAWSがTCP、TLS、GCPがTCP、UDPであること、AWSではパス / ホストベースのルーティングができるがGCPではできないなどです。
AWS:AWS Shield
AWS Shieldは無償で自動適用されますが、L3、L4レベルのDDoSが適用範囲のみです。
HTTP フラッド/キャッシュ無効化 (レイヤー 7) 攻撃のようなレイヤー7まで保護しようとするとAdvancedになります。
値段もAdvancedしていて3000ドル/月(年間36000ドル)です。
「AWS WAF および AWS Firewall Managerが追加料金なしで使える」と「AWS DDoS レスポンスチーム (DRT) 」を使い倒してコストメリットを出せるかが判断ポイントになりそうです。
(後、攻撃されてEDoSにならないように「Route 53、CloudFront、およびELB DDoSの料金に関連する払い戻し」がついてます。)
GCP:Cloud Armor
Google Cloud Armor は、インフラストラクチャ（レイヤー 3 および 4）への DDoS 攻撃に対する組み込み防御機能です。
料金は項目ごとの従量課金です。バックエンド サービスでユーザー定義のリクエスト ヘッダー機能を使用しても、この機能に対する追加料金はかからないなど例外となっているものがあるなど少し見積もりが困難です。
想定以上のコストになっていないか実データを根拠にシミュレートする必要があります。
ポリシーあたりの課金 Google Cloud Armor セキュリティ ポリシーあたり月額 $5
ルールあたりの課金 ルールごとに月額 $1、日割り計算
着信リクエスト課金 HTTP(S) リクエスト 100 万件あたり $0.75
脅威の検出、マルウェア検知 AWS:Amazon GiardDuty/GCP:Event Threat Detection
AWS:Amazon GiardDuty
CloudTrail、VPCフローログ、DNSログを監視し、AWS内の不審なアクティビティを検知するセキュリティモニタリングサービスです。
例えば、AWSの認証情報が漏洩した場合、EC2がマルウェアに感染し不審な通信が発生している場合などを検知します。
マルウェア検知に関してはAWS Security Best Practicesに記載があり、Trend Micro Deep Security(ホスト型IDS/IPSを含む)、Sophos Endpoint Protection(エンドポイント)が挙がります。
Amazon Inspectorを利用することで脆弱性診断に関してはEC2エージェントに対してインターネットから EC2 インスタンスにアクセス可能になっていないかどうか、リモートルートログインが有効になっていないかどうか確認できます。AWS のセキュリティ調査担当者が内容をアップデートするため、ベストプラクティスを調査費用を抑えて実施できる点を利点と謳ってます。
共通脆弱性識別子(Common Vulnerabilities and Exposures)、CIS オペレーティングシステムのセキュリティ設定ベンチマーク(CIS Operating System Security Configuration Benchmarks)、セキュリティのベストプラクティス(Security Best Practices)、実行時の動作の分析(Runtime Behavior Analysis)などが実施内容となっています。
CIS オペレーティングシステムのセキュリティ設定ベンチマークがAmazon Linuxでのみ利用可能など制約事項が存在する点に注意が必要です。
費用は最初の 250 回のエージェント評価（0.30 USD）次の 750 回のエージェント評価（0.25 USD）となっています。
Amazon Inspectorの始め方
①まずはエージェントをEC2内に設置する必要があるので以下の手順で設置します。
$ mkdir inspector
$ cd inspector
$ wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
$ sudo bash install
②Amazon Inspectorの評価ターゲットを作成します。
Amazon Inspectorを選択、評価ターゲット→作成を押下します。
次に具体的なターゲットを設定します。All Instancesにチェックを入れれば、エージェントが入っているすべてのインスタンスに対して実行となります。
Use Tagsで絞り込む場合はタグが必要になるため、GUIなりCLIなりでタグを設定して置く必要があります。CLIで–dry-runをつけるとテスト実行外すと本番実行となります。
テスト実行用：aws ec2 create-tags –dry-run –resources i-インスタンスID –tags Key=inspector,Value=True
本番実行用：aws ec2 create-tags –resources i-インスタンスID –tags Key=inspector,Value=true
③Amazon Inspectorの評価テンプレートを作成します。
ルールパッケージに評価したいルールを設定します。共通脆弱性識別子の場合はCommon Vulnerabilities and Exposures-1.1などと設定します。
SNS トピックは開始と終了のタイミングでSNSを飛ばしてくれるという設定です。
Assessment Scheduleは繰り返し定期実行するかどうかの設定です。デフォルト７日に一回でチェックを外すと単発になります。
ここまでできたら「作成」を押下します。
④Amazon Inspectorの評価を実行します。
実は前画面で「作成と実行」を押下すると実行できてしまうのですが、一覧から選択して内容の確認後実行します。
実行できると「データを収集中」に表示が変わります。
⑤Amazon Inspectorの評価実行結果を確認します。
左側のメニューの「結果」を選択すると結果を確認できます。各項目の詳細画面より推奨事項やリスクを勘案してネクストアクションを考えましょう。
GCP:Event Threat Detection
脅威インテリジェンスを使用しマルウェア、クリプトマイニング、Google Cloud リソースへの不正アクセス、外部 DDoS 攻撃、ブルート フォース SSH など、リスクが高く被害が大きい脅威を迅速に検出できるサービスです。サードパーティのセキュリティ システムに送信しSIEMと連携ができBigQuery に保存してフォレンジック分析に使用できます。
料金はEvent Threat Detection で分析されたログデータにつき 1 GiB あたり $0.25 の定額料金が発生します。BigQuery、Pub/Sub、Cloud Functionsなど関連サービスの料金も追加になることを忘れないようにしなければなりません。
ユーザ、APIのアクティビティを追跡 AWS:AWS CloudTrail/GCP: Cloud Audit Logging
Audit Taraiは監査証跡と訳され、特定の操作、手順、またはイベントにいつでも影響を与えた一連のアクティビティの文書による証拠を提供する情報群です。
AWS:AWS CloudTrail
AWS APIの実行の記録と監視を行いAPIの実行ユーザーやIPアドレスから事実確認を行うことができます。
GCP: Cloud Audit Logging
GCPプロジェクトにおいて自動的に有効化されています。管理アクティビティ、システムイベントログ、データアクセスログにより誰がいつ何を実行したか追跡できます。
機密情報の保護 AWS:Amazon Macie/GCP:Cloud DLP
AWS:Amazon Macie
S3に保存されたデータに対してデータ分類と異常アクセスの検出を行うサービスです。料金は有料です。
データ分類は機械学習を利用し、異常アクセスの検出はCloud Trailイベントログを利用しています。
CloudWatch Eventsと連動させてネクストアクションが設定できます。
GCP:Cloud DLP
メールアドレスや名前など定義済みの機密情報(90種類以上)を検出分類管理できるサービスです。
Cloud Pub/Sub、Cloud Functionsと組み合わせて置くことで検出完了時のネクストアクションが設定できます。料金は有料です。
検出結果は集めたデータの時点でマスキングが行われており安全に利用ができます。
DLP API(実態はREST API)と呼ばれるを利用することで、GCP外部に対しても実行可能です。
セキュリティとコンプラインアンスの可視化 AWS:AWS Secuirty Hub/GCP:Cloud Security Command Center
AWS:AWS Secuirty Hub
複数のサービスで発生したセキュリティアラートの集約や整理、優先順位付けを行い、一つの管理画面でわかりやすく見ることができるサービスです。
具体的には以下の５つのサービスを一元管理の対象としたものと理解してください。
①Amazon GuardDuty
②Amazon Inspector
③IAM Access Analyzer
④Amazon Macie
⑤AWS Firewall Manager
GCP:Cloud Security Command Center
組織が使用しているクラウド サービスやリソースのセキュリティ状態を明確に可視化するサービスです。
App Engine や Compute Engine、Cloud Storage、Cloud Datastoreなどあらゆるリソースを対象にできます。
Security Health AnalyticsはGCPインフラストラクチャを自動的にスキャンして、パブリックストレージバケットの設定やファイアウォールのポートに関する問題、古くなった暗号化キー、無効化されたセキュリティロギングなどの問題を検知できるため、Amazon InspectorのGCP版のようなイメージが近いのかもしれません。
変更管理（設定履歴の取得） AWS:AWS Config/GCP: Cloud Asset Inventory
AWS:AWS Config/AWS Config Rules/insightwatch
AWS Config Rules
EC2に専用のエージェントをインストールしてAWSの設定がルール通りに設定されているか確認するサービスです。
insightwatch
AWSの設定がCISベンチマークの基準を満たしているかチェックするサービスです。(クラスメソッドが提供(無料))
GCP: Cloud Asset Inventory
アセットとはリソースとポリシーを合わせた情報資産と理解しておくとわかりやすいです。
アセットに対する変更履歴やある時点でのアセットの状態を確認することができます。
以上です。参考になれば幸いです。