この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
今回はAWS Loftで開催された「AWS re:Invent 2018 Security re:Cap 第二部 ～セキュリティセミナー～」に参加してきましたのでレポートします。
レポート
AWSセキュリティサービスアップデート① AWS Control Tower
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 シニアセキュリティソリューションアーキテクト 桐山 隼人 氏
- まずはre:InentのSecurity情報から
- AWS Security Keynote
- AWSのCISOが喋った
- AWS Securityのイノベーション速度
- 2018年に239の新しいセキュリティ昨日を出した
- AWS全体としては1800以上のアップデートがあった、加速度的
- メッセージ
- Correction of Errors(CoE)の仕組みづくり
- 詳細な時系列情報収集
- ビジネス影響分析
- 原因特定
- 計測可能なアクション
- 再発防止
- Center of Excellenceではないよ！
- 自動化によるPace of Protectionの促進
- リアクティブな組織ではなくプロアクティブに動いていこう
- 新しいセキュリティ機能をどんどん出していく
- 人をデータから切り離す
- Attack Surface(攻撃対象となりうる面)最小化
- 脅威インテリジェンスの活用
- 人が手動で触っているとそこが問題になる
- Correction of Errors(CoE)の仕組みづくり
- 仕組みづくり -> 自動化 -> 人が介在しないようにする、という進化が大切
- 企業もそうなっていくべき
- Compliance certifications at launch
- 新しいサービスに対してもPCI DSSやISO27000に対応していく
- ユーザもすぐにサービスを利用できる
- これまではリリースから半年とかかかっていた
- 直近でISO認定したサービスが50くらいある
- 新しいサービスもたくさん含まれている
- AWSはBuilderを支えるプラットフォームと言える
- AWS Security Keynote
- Builderに必要なもの
- これまでの一般的な企業のセキュリティ担当者の役割は？
- ゲートキーパーのような役割
- AWSセキュリティはガードレールであるべきだ
- 何かを止めるために存在しているわけではない
- この道を進んでもらえればより良くなります、と指針を出す
- 開発チームの速度を緩めない
- ガードレールを実現するパーミッションの例
- アクセスポリシーのカテゴリは2つある
- Permission boundaries
- 例えばOrganization SCPsとかIAMのboundaries
- 開発者に対してガードレール(境界線)を提供する
- Permission policies
- 従来型のアクセス制限
- Permission boundaries
- この2つを組み合わせて行く必要がある
- アクセスポリシーのカテゴリは2つある
- 例えば日本ではDLPが流行らなかった
- 理由としてはセキュリティ部門がデータの重要度がわからなかった
- 事業部門でないと判断できない
- 役割を分けることが大事
- セキュリティ部門はboundariesを決める
- 事業部門ではpoliciesを決める
- これまでの一般的な企業のセキュリティ担当者の役割は？
- 4つのセキュリティコントロール
- Directive control
- Preventative control
- Detective control
- Responsive control
- ガバナンスとマネジメント
- ガバナンス
- ビジネスパフォーマンスの監視と評価に基づく意思決定と指示
- Directiveに集中
- マネジメント
- 指示に基づいてビジネス活動を計画構築実行し監査結果を報告
- Directiveにも関わりつつPreventative, Detective, Responsiveを行っていく
- ガバナンス
- 新しいサービス
- AWS Control Tower
- ガバナンスとしての役割
- 統制を効かせる
- AWS Security Hub
- マネジメントの役割
- いろんなデータを集める
- AWS Control Tower
- シークレットゲスト登壇
- ユーザ目線での新サービスの感想をたくさん伺いました
- 残念ながら非公開です！続きはまたの機会に！
- AWS Control Tower
- マルチアカウントに対応したセキュアな環境を簡単に設定及び管理できる
- ベストプラクティスに基づくAWS管理基盤を構築
- Organization, CloudTrail, IAMなどをステップバイステップでガイド
- セキュリティ/運用/コンプライアンス要件をパッケージ化したガードレール
- マルチアカウント環境でのチャレンジ
- 選択の矛盾
- 設定の複雑さ
- 継続的管理
- Control Towerの機能
- 自動化された設定
- ポリシーの確実な実施
- 監視用ダッシュボード
- LandingZone
- もともと出ていたControl Towerの構成要素
- 飛行機の滑走路のこと
- この道に沿うことが大切、という感じ
- マルチアカウント戦略
- Organizationsで各アカウントを作成
- Organizations Account
- Shared Service Account
- Log Archive Account
- Security Account
- セキュリティ担当者がアクセスする
- 逆にそれ以外の人はアクセスできない
- それぞれSSOでアクセス
- AWS Config, CloudTrail等の設定もされている状態でアカウントを払い出す
- Organizationsで各アカウントを作成
- Accounting Vending Machine
- 統制されたアカウントプロビジョニング
- AWS Service Catalogによるエンドユーザ構成とプロビジョニング
- 組織単位(OU)配下にAWSアカウント作成/更新
- ユーザアクセス
- AWS SSOによるシングルサインオン
- AWS Managed ADとの連携も可
- MS ADはShared Service Account内に作成
- セキュリティ管理者への通知
- 各アカウント通知用SNSトピックの生成
- CloudTrailやConfigなどの通知をSecurity Accountに集約
- CloudWatchやGuardDutyイベントもSecurity Accountに集約
- セキュリティベースライン
- 様々なサービスが対応している
- セキュリティリスクの方程式
- 一つの指標として 脅威 x 脆弱性 x 情報資産
- リスクの分析と可視化
- 各要素の分析結果を集める
- AWSのサービスとしては下記の3つ
- GuardDuty: 脅威分析
- Inspector: 脆弱性分析
- Macie: 情報資産分析
感想
なんでControl TowerやSecurity Hubが生まれたのかよく分かるお話でした！
Landing Zoneによりマルチアカウント戦略のベストプラクティスがよりしっかりと固まってきているので、これに沿って進化の速度を緩めないセキュリティをやっていきたいですね！
AWSセキュリティサービスアップデート② AWS Security Hub
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 シニアソリューションアーキテクト 藤倉 和明 氏
- まずはAWSのセキュリティワークフロー
- NISTのフレームワークに割り当てたもの
- Identity
- アカウントの管理
- SSM
- Config
- Protect
- 防御
- Shield
- WAF
- Detect
- 検知
- Inspector
- GuardDuty
- Automate
- 検知後のフローの一つ
- 手動でやっていたルールを自動化
- Lambda
- Step Functions
- Investigate
- 検知後のフローのもう一つ
- 自動化出来ていない部分を手動対応
- CloudWatch
- CloudTrail
- Respond
- Recover
- Snapshot
- Archive
- Identity
- NISTのフレームワークに割り当てたもの
- 直面しているセキュリティ課題
- 可視性
- セキュリティとコンプライアンスを一元的に見渡せない
- 優先順位付け
- 大量のアラートによる対応への優先順位付けが必要
- 複数のフォーマット
- 多くのセキュリティツールとそれぞれ異なるデータフォーマット
- コンプライアンス
- AWSインフラストラクチャがコンプライアンス要件を満たしていることを確実にする
- 可視性
- これを解決するためにSecurity Hub
- AWS環境全体でセキュリティとコンプライアンスを一元的に管理可能
- アラートを集約して時間を節約
- 優先順位付けの問題の概要を表示
- コンプライアンスチェックの自動化
- Public Previewで無料で使える
- 東京リージョンでも使える
- リージョンごと有効化する
- リージョンごとデータを共有しない(コンプライアンス目的)
- マネジメントコンソールからポチッとすると有効化で使える
- 現状取れるデフォルトの情報
- GuardDuty
- Inspector
- Macie
- 他にもサードパーティのセキュリティ製品と連携できる
- コンプライアンスチェックの際にConfig Ruleが作られる(ここは有料)
- AWS Security Hubの利点
- 複数AWSアカウントの結果を数分で集約しリージョン別にAWSサービスを管理
- 単一のコンソールでセキュリティ・コンプライアンス結果を管理することでデータ関連付け効率向上
- 環境固有の課題を追跡できるカスタムインサイト
- お客様の業界固有のインサイトを作成できる
- AWS Security Hubが解決する課題
- 可視性
- Amazon Findig Format(AFF)で標準化されている
- 各ベンダーも対応している
- 優先順位付け
- Insightで優先順位がついている状態で見れる
- フォーマット
- ダッシュボードで共通の表示
- コンプライアンス
- CISベンチマークによる標準ガイド
- 可視性
- 業界標準やベストプラクティスに基づくチェック
- CIS AWS Foundations Benchmarkに基づいた評価
- 結果はダッシュボードに表示されすぐにアクセス可能
- AWS Security Hub Insights
- 優先順位付けのために関連付けられたセキュリティ結果
- AWSでは35個、パートナーと合わせると100位上の定義済インサイト
- 自分自身でもインサイトを作成可能
- 優先順位付けのために関連付けられたセキュリティ結果
- マルチアカウント対応
- Response and remediation
- 出てきたリスクに対してカスタムアクションを定義可能
- CloudWatch Eventとして発火できる
- LambdaやStep Functionsを経由してSlackへ通知したり、EC2を落としたりできる
- githubでテンプレートも公開されている
- デモ
- 一覧からインサイトを見ていく
- ブルートフォースを受けている可能性があるアラート
- カスタムアクションからsend to email
- メールで情報を受け取ることができる
- EC2インスタンスのID等必要な情報がメールに入っている
- CISのコンプライアンスチェック
- CISのどの要件を満たしているか一覧が出てくる
- どのアカウントのどのリソースが対応できていないか確認でき、すぐ対応できる
- 設定
- マルチアカウントの連携
- パートナーソリューションとの連携設定
- 一覧からインサイトを見ていく
- 顧客事例
- プライベートベータで様々な顧客が利用済
- たくさんのパートナーとの連携がすでに可能
- まとめ
- セキュリティとコンプライアンスの状態を管理、理解できる
- 一つのリージョン内で風数アカウントのセキュリティ結果を集約し処理する
- 規制やベストプラクティスに沿ってコンプライアンスを評価する
- すべてのセキュリティ結果を一箇所に集めてグループ化しインサイトと相関させて確認できる
感想
すでに使えるサービスなのでぜひ使っていきたいですね！
ぜひ使ってほしいです。やってみたはこちらもご参照ください。
AWS Security HubとTrend Micro Deep Securityの連携デモその他
トレンドマイクロ株式会社
シニアセールスエンジニア 姜 貴日 氏
- AWS Security HubとDeep Securityの連携
- デモ1: Security Hubと連携
- Deep Securityはホストにインストールする総合セキュリティ対策製品
- 監視している端末でeicarをダウンロード
- Deep Securityで検知
- Security HubでもFindingsで検知内容が見れる
- デモ2: Event Correlation
- 今変更監視機能を使う
- 監視したいベースラインを設けて、変更が起きているか検知する
- あるEC2にポートスキャンを行う
- 通信用プログラムを配置
- C&C通信の準備(hosts変更)
- それぞれGuardDutyとDeep Securityで検知
- Deep Securityでは変更監視で不正なファイルが増えていることを検知
- hostsの変更も検知
- GuardDutyで外部向け通信を検知
- Security HubではDeep Security用のカスタムインサイトを作成(日本語が入る！)
- カスタムアクションで環境保全(ssm-aquire)とか
- 隔離・削除を実行できる
- 今変更監視機能を使う
- ユースケース
- グレーなものを黒に近づけていく、イベントの角度を高める
- 黒くなったものに対する定形アクション
- 実際にやる場合は下記を参照してください！
- デモ1: Security Hubと連携
- Deep Securityはコンテナ対応もしていくよ
- マイクロサービスのセキュリティも対応していく予定
感想
実際にサードパーティから集約できるところがよくわかりました。
ユースケースとしては、自動化が難しいところに役に立ちそうですね。
また、トレンドマイクロ様のマイクロサービスのセキュリティについての動向も気になりますね！
セキュリティ担当者から見た re:Invent と AWS Security Hub
クックパッド株式会社
インフラストラクチャー部 部長 星 北斗 氏
- ガードレールという話があったが、下記も参考になるよ！
- クックパッドでもたくさんのEC2等を利用している
- クックパッドではインフラ系だけでなくサービス開発者のre:Invent参加者も増えている
- re:Inventの感想
- セキュリティ系セッション、ワークショップ
- 大量にあった
- より高度なトピックに行くほど「コードを書いて自分たちで作っていく」物が多い
- 自分の分野以外のワークショップなどに出ているエンジニアも多い
- スライドや動画は公開されている
- Security Jam
- AWS上でセキュリティ対策やインシデントレスポンスを体験していくイベント
- 日本でやるかGateDayと時間をずらしてほしい！(切実)
- Expo
- セキュリティ製品のプロバイダは年々増加している
- 今年はコンテナセキュリティが多かった印象
- SIEM、イベントマネジメントなども
- 今年の発表
- いろいろありましたね
- セキュリティの発表少なくない？
- 直接セキュリティをターゲットにしたものは少ない
- が、セキュリティシステムの構築などに使えるものはたくさん
- セキュリティタグが付いたサービスだけがAWSセキュリティではない
- そういうところの話を掘り下げたい
- クックパッドでの一例
- CloudWatch Logs Insight
- CloudWatch Logsに対してログの絞り込みや集計、分析が可能
- JSONにも対応
- 新バックエンドによる爆速検索
- 大量のログデータに対して何倍も速い
- システムやアクセスログのストレージとして有力候補
- 値段は注意
- CloudWatch Logsに対してログの絞り込みや集計、分析が可能
- S3 Object Lock
- S3 Objectを一定 or 無期限で上書き/削除できなくなる機能
- 最強のモードではrootでも削除不能
- MFA Deleteに代わる選択肢になる
- 各種重要ログの保持に利用可能
- 誤爆には注意
- 監査のためにも使える
- S3 Objectを一定 or 無期限で上書き/削除できなくなる機能
- S3 Glacierの機能強化
- 名称変更と同時にいろいろ出た
- S3 Glacierストレージクラスへの直送
- クロスリージョンレプリケーション対応
- 復元通知。、復元速度アップ
- Deep Archive
- かさみがちなログの長期バックアップ
- S3 Intelligent Tiering
- S3 StandardとStandard-IAを自動で行き来できる
- Athena などをログ検索に使っているケースでは便利
- フルスキャンすると意味がない
- KMS Custom Key Store
- KMSのキーストアとしてCloudHSMが使えるように
- AWS Control Tower
- 説明済なので省略
- カジュアルにAWSアカウントを作り安くなる
- 既存アカウントへの適応がどうなるか気になる
- AWS Security Hub
- もう少し掘り下げる
- セキュリティシステムの基本方針
- 様々なソフトやサービスをセンサーとして使う
- ログやアラートを集約して管理する
- それぞれのコンソールにログインすることはやめる
- 本当に必要な判断に集中できる仕組みを作る
- 利用しているアーキテクチャ
- ログ収集パート
- S3にまとめる
- ログ処理パート
- ストリームでLambdaへ
- アラート処理パート
- 処理する
- キャッチしたアラートは正規化してGitHub
- 初期調査は自動
- PagerDutyに通知
- ログ収集パート
- 例
- PagerDutyからのアラート
- GuardDutyのもの
- リモートIP等の情報がある
- checkip.amazonaws.comで確認する
- AWS LoftのIPだった(正常系)
- 改善したいポイント
- アラートの正規化がちょっと大変
- アラート自体の集計可視化
- 自動化を進める
- アラート正規化
- 対応しているサービスであればSecurity Hubでは正規化不要
- 他システムにアラートを書き込みたい場合もSecurity Hubを挟めば共通化できる
- アラートはとりあえずSecurity Hubへ
- 他のサービスも統合されるのでは？
- 対応しているサービスであればSecurity Hubでは正規化不要
- Amazon Security Finding Format
- セキュリティアラートに求められそうな項目は一通りカバー
- EC2インスタンスIDやAWS固有のフィールドも用意
- 今の段階ではAWS無いリソースを主に想定しているように見える
- もうちょっといろいろなリソースに対して使えると嬉しい
- 詳細はSecurity Hubのドキュメントを参照
- 集計、可視化
- Insightである程度可能
- Findingsをフィルタした結果(Group byなども可能)
- グラフもカスタムできたら嬉しい
- 長期的に怪しそうなリソースを見つけるのにも有効
- 自動化
- CW Eventにイベントを送信できる
- Finding, Insight, Standards
- LambdaやStep Functionsを呼ぶことができる
- ログ収集と紐付け、レピュテーション調査、検体調査、インスタンスへのコマンド発行等なんでもあり
- CW Eventにイベントを送信できる
- その他
- マルチアカウント対応
- Control Towerで新規作成時に全セキュリティサービス有効化 + Security Hubへの送信ができるようになるかな？
- セキュリティ標準への対応
- マルチアカウント対応
- その他こうなってくれると嬉しい
- Findingsそのもののアップデート
- 自動化した調査結果とか書きたい
- イベント管理ツールとの連携
- AWS WAF連携
- アラートが多くなるはずなので、そのまま表示してほしくはないがうまくまとめてほしい
- Findingsそのもののアップデート
- まとめ
- すぐに使えるものが多くてよかったと思う
- セキュリティに直接フォーカスしたものは多くないが活かすことができるサービスや機能が出ている
- Control Tower, Security Hubは積極的に利用していきたい
- これからのAWSセキュリティ
- 特定のサービスやソフトを使うだけでなく広い視野でセキュリティシステムを設計して実装する
- AWSが提供しているものを使えばいい感じになる
- 次世代のセキュリティ環境を作っていくメンバーも募集しています！
感想
細かいセキュリティ関連の機能もたくさん出ていて頼もしいですね！地味な機能もしっかり紹介されていて参考になりました！
いろいろなサービスを連携してセキュリティ周りも自動化・効率化していきたいですね！
まとめ
新しいサービスの情報盛り沢山でした。パートナーからの話やユーザ目線の話も豊富で楽しかったです。
ユースケースもいろいろ情報が出てきているので使っていきましょう！
14
