こんにちは、ひろかずです
re:Invent セキュリティ方面の振り返り会に行ってきました
会場は、aws loft tokyo
シャレオツ空間がセキュ勢が詰めかけるアツい空間になりました。
アイスブレイクでは、RobomakerやDeepRacerは、既存のAWSサービスを組み合わせてキャッチーなサービスに仕立てた話
それぞれを組み合わせて、高速でイノベーティブなものを創り出すビルダー
という文脈が語られました。
おしながき
- AWSセキュリティサービスアップデート① AWS Control Tower
- AWSセキュリティサービスアップデート② AWS Security Hub
- AWS Security HubとTrend Micro Deep Securityの連携デモその他
- セキュリティ担当者から見た re:Invent と AWS Security Hub
AWSセキュリティサービスアップデート① AWS Control Tower
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 シニアセキュリティソリューションアーキテクト 桐山 隼人
セキュリティKeynoteの話
イノベーションの速度
AWSは、2017年に239のセキュリティ機能をリリースした
AWS全体では、1800以上の機能がリリースされている
加速度的なリリース速度
セキュリティ運用の仕組みづくり
CoE(Collection of Error)という考え方。これを仕組み化する
- 詳細な時系列情報の収集
- Business影響分析
- 原因特定
- 計測可能なアクション
- 再発防止
リアクティブからプロアクティブなチームになるために
- 自動化
- Pace of Protection
- インシデントがあろうがなかろうか、自分たちで機能を生み出していく
人をデータから切り離す
- 攻撃面の最小化
- 人がデータを触ることをやめる
- データを触るのはツール(Toolingという)にする
これらは、セキュリティチームの進化の段階
ビルダーは新しいものをどんどん取り込んで、新しい価値を生み出していく
新しいサービスが使えない障壁
- コンプライアンスの話
- コンプライアンスを高速に準拠することで、ビルダーは新しい機能をすぐに使えるようになる
- ローンチ時点でISO準拠したサービスが幾つもある
ビルダーに必要なものは?
セキュリティチームはどう見えていた?
- ゲートキーパー?
- ガードレール?
AWSはビルダーのためのプラットフォームなので、セキュリティチームはガードレールであるべきだ
- Businessを止める存在ではない
- ここを進めばいいという指針を出す存在になる。これがこれからのセキュリティチームの役割になる。
ガードレールの実現
例:Permission
- Permission BoundaryやSCP(Organization)
- 従来のPermission Policy
例:情報漏えい(DLP)
- 日本では流行らなかった
- このデータが重要なのかは、事業部門でないとわからなかったので、管理者がPolicyを書けなかった
- 統制側は、Boundaryを定義する
- 細かい設定は、事業部門で定義する。
例:ロサンゼルスの帰りの便が遅延した話
- ロサンゼルス空港は、超ハブ空港
- 高度なコントロールで運営されている
4つのセキュリティコントロール
- 分類
- 発見
- 対応
- 軽減
ガバナンスとマネジメント
- ガバナンスは、監視と評価に基づく意思決定
- 管制塔の人
- マネジメントは、Business活動の計画構築実行と結果の報告
- 地上勤務の人
ガバナンス向け
- AWS Control Tower
マネジメント向け
- AWS Security Hub
Secret Speaker
ここは、公開禁止のようなので自粛しますー
気になる人は、会場に足を運びましょう!
AWS Control Tower
マルチアカウントに対応したセキュアな環境を簡単に設定、管理
ベストプラクティスに基づくAWS管理基盤を構築
マルチアカウント環境での チャレンジ
- 選択しが多すぎる
- 設定の複雑さ
- 継続的管理
AWS Control Towerの機能
- 自動化されたAWS設定
- Policyの確実な実施
- 監視用ダッシュボード
Landing Zone
- 去年からあったソリューション
- 滑走路のようなもの
- ここを走ればいいよってもの
マルチアカウント戦略
- 共有サービスアカウント(ユーザーアカウント管理とか)
- ログ保管アカウント
- セキュリティアカウント(セキュリティログを収容)
アカウント自動販売機
- 統制されたアカウントプロビジョニングのデザインパターン
- ボタンを押したら、決まった構成のAWS
- AWS Service Catalogによるエンドユーザー構成とプロビジョニング
ユーザーアクセス
- AWS SSOでシングル・サインオン
- AWS ADとの連携
- 共有サービスアカウントに配置して、各アカウントで使えるようにする
管理者への通知
- 各アカウント通知用
セキュリティリスクの法的式
- 脅威(GuardDuty) x 脆弱性(Inspector) x 情報資産(Macie)
- リスクを分析するということは、各要素を分析するということ
- Security Hubは、これらを分析と可視化する
AWSセキュリティサービスアップデート② AWS Security Hub
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 シニアソリューションアーキテクト 藤倉 和明
従来のAWSのセキュリティワークフロー
識別
- ssm,config
保護
- VPC,SG。Shild,WAF,SSO,KSM,HSM,IAMなど
検知~自動化
- Lambda, StepFunction
検知~インベスティゲート
- Cloudwatch, CloudTrail
復旧
- Snapshot
- Archive
セキュリティの課題
可視性
- セキュリティとコンプライアンスを一元的に見渡せない
通線順位付け
- 大量アラートの優先順位分類が大変
複数のフォーマット
- 多くのセキュリティツールと異なるデータ・フォーマット
コンプライアンス
- コンプライアンス要件の準拠性
AWS Security Hub
アラートを集約して時間を節約
- GuardDuty, Inspector, Macie, コンプライアンスチェック,
優先順位付けの問題の概要を表示
- 数分以内に統合ダッシュボードに表示
コンプライアンスチェックの自動化
- CISベンチマーク
東京リージョンで使える
- リージョン毎に有効化する必要がある
- リージョン間でデータを
- Config Ruleが作られるので課金対象になる
利点
- 複数AWSアカウントの結果を数分で集約して、リージョン別にAWSアカウントサービスを管理
- 単一コンソールでセキュリティこんyプライアンス結果を管理
- カスタムインサイトで環境固有の課題を追跡できる
境界標準やベストプラクティスに基づくチェック
CISに基づいた評価
結果はダッシュボードに評価される
課題修正のためのベストプラクティスを提供
- 一部は、手動で評価しないといけない
Insights
優先順位付けの耐えに関連付けられたセキュリティ結果
- 100以上の定義済みインサイト
- カスタムインサイトも作れる
- ダッシュボードで優先度が高いものからヒョ応じ
- それぞれの評価の詳細も参照できる
マルチアカウント対応
レスポンスと修復
- CloudWatch Eventから、LambdaやStep Function
- GithubにCloudFormationテンプレートが載ってます
まとめ
- セキュリティとコンプライアンスの状態を管理して理解できる
- 複数アカウントに対して、リージョン単位でコンプライアンスの監査結果を収集して処理
- 規制やベストプラクティスに沿って対応できる
AWS Security HubとTrend Micro Deep Securityの連携デモその他
トレンドマイクロ株式会社
シニアセールスエンジニア
姜 貴日 氏
AWS Security HubとTrend Micro Deep Securityの連携
Demo1
DSで飛ばしたウィルス検知イベントをAWS Security Hubで拾う
- DSのマネージャで検知した後は、ほぼ即時に検出されました
Demo2
カスタムインサイトには日本語も入る
ポートスキャン
DSから変更検知イベントが挙がる
DSからhostsへの変更検知を
アクションで、保全や隔離、削除を行うスクリプトを実行する
使い所のポイントとしては、グレーなものを重ねて、黒に近づける(確度を高める)使い方がいい
Deep Securityの方向性
マイクロサービスへの方向性に舵を切っている
セキュリティ担当者から見た re:Invent と AWS Security Hub
クックパッド株式会社
インフラストラクチャー部 部長
星 北斗 氏
ガードレールについて
- 最近、自由でセキュアな環境のつくりかたという登壇をしました
セキュリティ系セッションとワークショップ
毎年だが大量なセッションがある
高度なトピックになると、自分でコードを書いて作っていくというモノが多い
セキュリティエンジニアが自分の分野以外のワークショップに出ていることも多い
スライドや動画は公開されている
Security Jam
AWS上のセキュリティ対策やインシデントレスポンスを体験していくイベント
Game dayとかぶっていて出られなかった
Expo
めちゃくちゃ広い
セキュリティ製品のプロバイダは年々増加している
Containerセキュリティが多かったかも
SIEMやイベントマネジメントも見かけた
今年の発表
MLやIoT、Robotもありつつ、堅実な領域にも大量のリリースがあった
直接セキュリティに係るアップデートは少なかったが、セキュリティシステムの構築に使えるモノがたくさんあった
- セキュリティタグだけが全てではない
セキュリティシステムのアップデート
Cloudwatch Logs Insights
- 絞り込みや集計、分析が可能になった
- 検索が爆速になった。大量なログも対応できる
- システムログやアクセスログなどのストレージの有力候補
- 価格は要確認
S3 Object Lock
- 一定期間、無期限で上書き、削除d毛生なくなる機能
- 最強モードではrootでも消せない
- MFA Deleteに代わる選択肢
- 各種重要ログの保持に利用可能
- 誤爆には注意
S3 Gracierの機能強化
- S3 Gracierストレージクラスへの直送
- クロスリージョンレプリケーションのGracier対応
S3 Intekkigent Tireing
- アクセスするとスタンダードに戻ってくる
- Athenaでフルスキャンすると、全部戻ってきてしまう
KMS Custom Key Store
- 激渋
AWS Control Tower
- 大量アカウントを管理する環境化では便利
- カジュアルにAWSアカウントを作ることができるようになる
Security Hub
Securityシステムの基本方針
- 様々なソフトウェアやサービスをセンサーとして使う
- センサーからのログやアラートを集約して管理する
- 本当に必要な 判断に集中できるようにする
ログ収集方針
- S3へ収集
- GuardDutyなども利用する
- 収集したログアラートの正規化をして、Graylogで分析
curl http://checkip.amazonaws.com/
更に改善ポイント
- アラートの正規化がちょっと大変
- アラート自体の集計や可視化
- 自動化を更に進める
- 調査、対象、長期的な分析
正規化
- 対応サービスなら正規化不要
- Security Hubを挟めば処理を共通化できる
- アラートはSecurity Hubに突っ込むことができる
- 今後の新しいSecurityサービスが出ても統合される
Security Finding Format
- Securityアラートに求められそうな項目は一通りカバー
- EC2インスタンスなどの固有のフィールドも用意されている
- いまの段階ではAWSにないリソースを主に想定しているように見える
- もうちょっといろいろなリソースに対して使えると嬉しい
集計、可視化
- Insightsである程度可能
- Findingsをフィルタした結果(group byも可能)
- グラフもカスタムできたら嬉しい
自動化
- Cloudwatch Eventsにイベントを送信できる
- FIん金gInsight Standards
- LambdaやStep Functionを呼べる
その他
- マルチアカウント対応
- ControlTowerで新規作成時に全セキュリティサービス有効化やSecurityハブへの送信はできるといいな
- セキュリthい標準のチェック
希望
- Findingsそのもののアップデート(属性の追加など)
- 自動化による調査結果などを更かしておきたい(現状テキストのみ)
- AWS WAF連携(アラートはかなり多いので、調整が必要そう)
今回の発表に付いて
- 次ぐに使えるものも多くてよかった
- Securityに直接フォーカス
これからの AWSのSecurity
- 特定サービスやソフトウェアを使うだけで花く、広い視点でSecurityシステムを設計して実装する
- パーツは揃っている
おわりに
AWSセッションは、表層的な大本営発表に留まらず、re:Inventで示されたAWSを使っていく上での考え方や方向性が色濃く出ていたのが印象的でした。
また、ユーザーセッションは、現場感溢れる生々しい話が聞けました。
毎回思いますが、会場に足を運んで良かったと思います。
今日はここまでです。
お疲れ様でした。