イベント詳細: Developers.IO 2019 Security｜EventRegist（イベントレジスト）
良く出たキーワードや考え方
- 責任共有モデル
- 検知と可視化
- GuardDuty
- すべてのセキュリティ要件を是正する必要はない、自社にとって適切な運用をしよう
- 自社で責任を持つ部分はパートナーサービスを利用することで負荷を権限できる
はじめに
セキュリティ対策って大変
- 様々なサービスがあるが、どれを選ばばよいかわからない
- セキュリティ事故はインパクトが大きく責任も大きい
- でも難しい
- コスト削減が求められる...
どのように選択すれば良いのか、理解して適切に取捨選択して使えるようにという話しをします
AWSでのセキュリティをどのように考えるかという視点が多め
AWSセキュリティ入門
スライド: 公開されたらはる
登壇者: アマゾン ウェブ サービス ジャパン株式会社 パートナー技術本部 SaaS パートナー ソリューション アーキテクト 清水毅氏
好きなAWSサービス:
- AWS Certificate Manager
- Amazon GuardDuty
サマリ
- awsは金融関係でもクリアできるセキュリティを担保している、ちゃんとやればオンプレより安くて安全!
- セキュリティを最優先に考えているので様々なサービスが提供されている
- ボタンひとつで有効化できる機能も沢山ある
- ロギング、検知、可視化が大切
- サービス固有のセキュリティ要件はパートナーサービスを利用するのがおすすめ
- awsのサービスはプラットフォーム寄りで一般的な対策がメインだから
スライドのながれ
- AWSのセキュリティの考え方
- AWSのセキュリティサービス
- パートナーソリューションをどのように取り入れるのか
伝えたいポイント
- クラウドセキュリティはAWSの再優先事項
- 責任共有モデル
- AWSセキュリティの基本サービスとパートナーソリューション
AWSのセキュリティ、無料で使えるものもある
セキュリティが難しい理由: 可視性の不足、自動化される割合の低さ
ビジネスの俊敏性 OR セキュリティの確保
トレードオフなものだった、AWSを使うことで両方担保できる
web app ではデータ漏洩の頻度が多くもっとも重要なセキュリティ対策の一つ
会社情報 DTCC | DTCCから、オンプレよりもクラウドの方が上回ったという話しもある
AWSを使うことで金融関係でもクリアしているハードルを担保できるというのが世界の認識
日本では、UFJがAWSに移行するという宣言をした(2年前の話)
AWS x セキュリティ 「責任共有モデル」
AWSのセキュリティ統制はどうなっているのか?
AWSが取得しているコンプラがある、AWSクラウドにまかせている部分は自社で管理しなくても達成できる
なので自社で管理している部分だけコンプラを満たすように実装するだけでコンプラを準拠できる
とはいえ、自社でやるのも大変、お客さま固有のセキュリティ要件を満たすための情報、サービス、ソリューションを提供している
驚異検知できてますか?
驚異検知が難しい理由、
- 見る範囲が広く大量のデータセットが必要
- データはあっても検知するには高い検知精度が必要
- 日本では特に、それらを行う人材とスキルの不足
日本は驚異検知ができるでにかかる時間がとても長い...
データ侵害の検知では、攻撃が始まって数分で攻撃が成功している
人間がそれらを監視し続けるのは難しい、いかに自動化するかが重要
guarddutyはボタンひとつで有効化できて、内部的に取っているデータから脅威を検知する仕組みを提供してくれる
SecurityHubではAWS上で検知したものを可視化してくれる
AWS well architected Framwork
設計運用の考え方とベストプラクティス
全部やると多くが真っ赤になる、必要な部分だけやるようにする
パートナーサービスは高度に複雑なことをやりたいなら利用するとよい
基調講演
クラスメソッド株式会社 AWS事業本部コンサルティング部 臼田佳祐
クラスメソッド株式会社 AWS事業本部コンサルティング部 阿部洸樹
スライド1: 「AWS上のセキュリティ対策をどういう順序でやっていけばいいか」という話をしました~Developers.IO 2019 Security登壇資料~ ｜ DevelopersIO
スライド2: 「弊社の取り組みと事例」を話しました~Developers.IO 2019 Security登壇資料~ ｜ DevelopersIO
guardduty の検知例
- 起動してしばらく経過したEC2のメール送信
- 普段ログインしないIPアドレスからAWSコンソールにログイン
他の情報と合わせて正当性を確認
- VPCフローログ: いつから異常な通信が発生したのか
- CloudTrail: 異常なIAMユーザーのアクティビティを一覧化
guarddutyは格安で利用できるし実際有効なので使いましょう!
AWSのセキュリティ設定がどうなっているか抜け漏れなくちゃんと確認する方法 2019 SPRING
クラスメソッド株式会社 AWS事業本部プロダクトグループマネージャー 田子昌行
同上 AWS事業本部コンサルティング部 吉井亮
スライド: 公開されたらはる
aws環境でのセキュリティ対策の進め方
awsには利用用途に合わせて沢山のサービスがある
アップデートも頻繁
s3などの漏洩事故は起きてしまう
どうやって背きゅうりティ対策をしてくか
3段階に分けて考える
- 責任範囲の理解
- 現状把握
- 対策
AWS re:invent 2018 良いので見てみてください
責任範囲を理解するために
責任共有モデル - AWSにすべて任せられるわけでなはい
awsがベストプラクティスを公開している
CISベンチマーク
PCIDSS、NISTなど
CIS AWSベンチマーク、awsの設定に関する網羅的な評価基準が提供
以下の4つのカテゴリに分けて49項目ある
- IAM
- ロギング
- モニタリング
- ネットワーキング
これらをクリアすることで最低限が担保できる
see:
- CIS AWS Foundations Benchmark | AWS Security Blog
- あなたのAWSセキュリティ監査状況を採点〜CISベンチマークを読んでみた ｜ DevelopersIO
自社のインフラは大丈夫?
IAMアカウント多い、大変
aws insightwatchがおすすめ
誰でも簡単に、aws環境がセキュリティのベストプラクティスに沿っているかどうかを強化できるサービス
CISベンチマーク、IAMベストプラクティスなどのセキュリティチェックやその結果のレポート設定ガイドも提供
insightwatchはCIS認定サービス
レポートでは、どのリージョンのどのアカウントで問題があったのかわかりやすく表示される
組織とプロジェクト単位で聖地することができプロジェクト単位でチェックを行うことができる
CIS AWS 1.1と1.2の違い
大幅な変更はなし
awsの機能が変更されたのでそれの適用がメイン
新機能としてWebhookが発行できるようになったのでスケジューリングが容易になった
対策する
CISはあくまで基準
闇雲に対策するのではなく、自社の助教に応じて対応すること
ポイント
- 責任範囲の明確化
- 課題の可視化
- 対策の実施と継続的な評価
小さな発見と対策が事故の発生を防止し大きな安心につがります
事例紹介とQ&A
継続的にセキュリティチェックおｗしている企業はどうやっているのか?
導入先: 匿名
弊社との関係: データセンターで運用しているサービスをAWSへ移行したい
社内外セキュリティ規定への準拠していると胸をはって言いたい
サイクルを作るのが重要
- 設計フェーズ
- CISベンチマークやベンチマークをチェックできるように設計する
- 原稿のサーバーセキュリティ規定はある、オンプレ基準なのでAWSに合わないという話しがある
- 気持ちでチェックする
- 構築フェーズ
- すべてを指摘のまま是正すると手間のわりに得られるものが少ない
- 不要なものは除外する
- 運用フェーズ
- 注意と需要とマークされても
- 犯人さがしはしない(aws configでできる)
- 発見できてよかったねとポジティブに捉える
ポイント
- 情シス担当の強い気持ちで進める
- セキュティチェックする前提の設計を行う
- 犯人探しはしない
AWSアカウントの現状を把握できてますか？それ、Dome9でよく見えますよ。
サマリ
AWSを大規模有用するうえでIAMの管理やクラウドサービスの設定ミスを検知してインシデントを防ぐならおすすめ!
SecurityGroupやIAMの集中管理や一時的な特権の付与機能がある
AWS Marketplace: Check Point CloudGuard Dome9
Dome9 | クラウドセキュリティ | ソフトバンク
ソフトバンク株式会社
IoT&セキュリティ事業推進部 担当課長 田頭直樹氏
スライド: 公開されたらはる
dome9とは: awsユーザーの管理責任部分を手軽にカバー
ネットワーク、継続的なコンプラチェック、IAM管理、クラウドの脅威インテリジェンスなど
責任共有もでるのお客様の部分をどうやってやっていくかという部分を手軽にできるように
なぜソフトバンクがやっているのか、2017年4月に戦略的投資を行った一つがDome9
assess(評価)、修正、管理のサイクルをコンセプトにしている
チェック・ポイント・ソフトウェア・テクノロジーズ株式会社
セキュリティ・エバンジェリスト 卯城大士氏
スライド: 公開されたらはる
CloudGuard: 包括的なクラウド・セキュリティ
ユースケース:
攻撃者がパブリック・クラウドのアカウントをハイジャックし仮想通貨のマイニングに利用
AWS上でk8sを運用
セキュリティは設定できるが
L3レベルの基本ファイアウォール、限定的なセキュリティ、テキストベースの設定
ミス設定が起こりがち...
検知できるポイントとしては、以下があり適切にロギング、検知することができれば気づいて対策できる
- サーバーへの不審なアクセス
- 意図しないクラウド設定の変更
- サーバー内でのマルウェアの動作
- 意図していない外部へのトラフィック
クラスメソッド株式会社
AWSソリューションアーキテクト 中山 順博
スライド: 公開されたらはる
ネットワークの可視化が優秀
ルールセットと要件の紐づけができるので、適切な設定ができているかがわかりやすい
許可を与えるときは一時的だったが、削除しわすれるというケース
指定した時間を超えると自動で許可を削除してくれる機能がある
IAMの管理権限を持つ = 新たな管理者を生み出せる
- 1人だけが管理するというのも危険
- その人がいなくなると誰も触れなくなる
- 多くの人がIAMを持つのも危険
- 一時的に特権を渡すという機能がdome9にはある
マルチアカウント戦略
メリット
- コストの識別
- 範囲の限定
デメリット
- チェックするアカウントが増えてしまう...
AWSを安心・安全に利用する上で知っておきたい最適なセキュリティ対策とその最新動向とは？
スライド: 公開されたらはる
トレンドマイクロ株式会社 セールスエンジニアリング部 シニアソリューションアーキテクト 姜貴日氏
サマリ
- サーバーセキュリティのポイント
- 脆弱性対策、多層防御、クラウドフィット
- 最近の脅威動向
- クラウドが伸びるにつれてそれに関連したソフトウェアの脆弱性対応が重要になってきている
総合サーバセキュリティ - Trend Micro Deep Security | トレンドマイクロ がおすすめ!
AWSのセキュリティ対策をどうするか
IaaSに焦点を絞って話す
責任共有モデル、クラウドサービスはIaaSとSaaSの部分を責任を持つ必要がある
サーバーセキュリティのポイント
- 脆弱性を利用した攻撃への対策(脆弱性対策)
- 2017年に流行った、Apache Struts2の脆弱性
- 現在でも頻繁に使われているので、古くても重要な脆弱性には対応が必要
- 実際に攻撃してみる、デモ動画あり: see スライド
- 様々な攻撃手法に対応する仕組み(多層防御)
- クラウドのメリットを阻害しない実装(クラウドフィット)
- ネットワーク型
- ホスト型
最近の脅威動向
クラウド関連ソフトウェアの静寂性
クラウドが伸びるにつれてそれに関連したソフトウェアの脆弱性対応が重要になってきている
dockerエンジン、k8s、docker runcなどの脆弱性など
設定不備による情報漏えい
- S3のアクセス制限のミス
- 顧客情報がクラウド上で公開
- 米軍の極秘情報がAWSで公開情報だったことが発覚 100GB超のデータ
- 見つけた人は最初最初罠なのでは？と逆に疑うくらい簡単にアクセスできてしまった...
不正な仮想通貨発掘の手口
脅威の傾向: ランサムウェア => 不正マイニング
ランサムは身代金要求したら終わり、また次を見つける必要がある
マイニングはバレない限りいつまでもリソースを使えるのでこちらに傾向が移りつつある
S3の設定不備による仮想通貨マイニング事例
s3の書き換えが可能、マイニングが可能なjsファイルが書き込まれユーザーがアクセスする度に不正にマイニングが実行されていた
不正マイニングで求めているもの = クラウドのメリット
- 処理能力が高く、スケールしやすい環境をお手軽に確保 (PC => サーバー => コンテナ)
- 設備投資が不要で潤沢なりソースを確保できる(オンプレ=>クラウド)
- 長い期間に渡ってマイニングが行える(クラウドアカウントを乗っ取り、検出リスクを軽減)
コンテナ技術を不正に利用した不正マイニングの事例
- コンテナを利用した不正マイニング
- k8sの設定不備によるマイニング
- 不正なコンテナイメージを利用したマイニング