【JAWS DAYS2019レポート】AWS環境のセキュリティ運用(設計)をはじめてみよう #jawsdays #jawsug

はじめに

2/23(土)に開催されたJAWS DAYS2019のセミナーレポートです。 走り書きの部分もありますので、内容に不備がありましたらご了承ください。

JAWS DAYS2019のテーマ

満漢全席召し上がれ

jawsdays2019.jaws-ug.jp

以下、セミナーレポートです。資料丸写しではなく、口頭で話していたことを中心に書いています。

テーマ

AWS環境のセキュリティ運用(設計)をはじめてみよう

クラスメソッド　臼田　佳祐さん

AWS WAF マネージドルール大好き！

dev.classmethod.jp

今日のコンセプト

なるべく楽に強く守る

オンプレ時代よりも辛くなったら意味がない！

• セキュリティ設定
• 脆弱性診断
• パッチ当てなど

人力でやる必要ある？？？ 何でも運用に投げない。設計で潰す！

基本的な環境

全てのアカウントで使うべきサービス

• CloudTrail
  • EC2起動・停止なども全部API
  • ログに取れる
    • ログがないとAWS助けて！と言えない
      • ユーザにはログを取る・取らないの権利がある
• AWS Config
  • リソースの構成や変更を可視化できる
  • 変化をトラッキングできる
    • 何時何分にEC2起動、何時に停止、何時に起動、タグが●●に変更された
    • リソースを主軸に時系列で確認できる
      • どういう操作をされたのか？
      • 全員必須！
• GuardDuty
  • 驚異検知のマネージドサービス
  • ビットコインのマイニングしてる通信の検出など
  • 1発有効化できる

• AWS Shield

  • DDおｓ保護サービス
  • L3/L4レベルが保護されている
    • Standardは特に設定は不要
  • AdvanceはL7

• どれもいざという時に役立つもの

  • ログは普段から取っておかないと意味がない
  • 料金は微々たるもの
    • EC2一台のほうがよっぽどお金かかる
• 上記4つのこれらの費用対効果は絶大！！

理想の構成

• 一般的な構成
  • 3層ネットワーク
    • フロント以外はPrivate
  • マルチAZ
  • オートスケーリング
    • EC2が死んでも回復できるように
  • 外部通信はNAT経由
    • Publicに置くのは良くない
  • 必要に応じてWAFなど入れる
• アンチパターン
  • PublicSubnetのみ
  • 冗長化されてない
  • サービスと管理アクセスが同じIP
  • スケールしない
  • インスタンス落ちたら復旧しない
• 設計の基本
  • 障害が起きることを前提に組む
• 最低限
  • マルチAZ
    • AZ障害がなくてもインスタンスが死ぬ可能性ある
      • リアイアメント
      • メモリリークなど
  • オートスケーリンググループに入れる
    • インスタンス1台でも使うべき
      • 1台でも台数を維持してくれる
      • ずっと死んだままよりは復旧したほうがいい
      • 後から簡単に増やせる
  • ELB、NAT Gatewayを使ってEC2はプライベートにする
    • ELBは1台でもメリットある
      • TLS終端できる
        • HTTPS対応
        • 証明書管理が不要になる
      • AWS WAF使える
      • EC2切り替え簡単
        • メンテなど
        • 違うバージョンに切り替えなど
      • HTTP周りのメトリクス収集
        • EC2だけだとメモリやCPUなどのIOしか見れない
        • 20X、40Xなどのメトリクスが取れるので監視が楽になる
• もう少しがんばるなら
  • CloudFrontでコンテンツをキャッシュする
    • 何ならバックエンドはS3にする
      • 静的なサイトを公開するならEC2よりもS3がいい
        • ミドルウェアがなくなる
        • 費用対効果、運用もめっちゃ楽
  • WAFを使う
    • マネージドルール使う
    • 要件が明確ならベンダがチューニングしてくれる

セキュリティグループ

• NACLは最低限でOK
  • アクセス制限はSGに寄せたほうが楽
• 役割ごとのSGをつくる
  • ALB用
  • WEB用
• 役割間はSGのIDで許可する
  • IPよりもセキュア
• 一時的な作業は、作業用SGを作ってアタッチしたほうが良い
  • すでにあるSGの中身は書き換えない
    • 事故防止

IAM

• 人が使うIAMはMFA必須
  • 無いと簡単に抜ける
• 人が使わないIAM Userは最低限にする
  • Roleを積極的に使う
• 複数アカウントまたがる場合は、1つのアカウントにIAM Userを集約する
  • SwitchRoleする
• 管理者だけでなく、開発者も作れたほうがいい

障害復旧方法

• EBSスナップショット
• AMI
• CloudFormationテンプレート
• データ・ログはS3に出しておく

あるある失敗

• IP固定化
  • FQDN使う
  • 動的な値は、SSMパラメータストア
• EC2のログがない
  • ログはS3に出す

AWSだけではできない対策

• アンチマルウェア
• 侵入検知

監視の設計

• 以上に気付くには監視が必要！
• メトリクス設定
• アラーム設定
  • restard httpd　自動化できる
  • EC2再起動も自動化できる
  • EC2削除は、Scalingの設定しておく

SSM

• ここからが本題ですwwwwwwwww
• 脆弱性の管理は自動化したい・・・
  • AWS Systems Manager
    • Agentで動作
    • EC2にログインしなくてもいろいろできる
      • RunCommand
        • $ systemclt status httpdとかできる
        • SSHポート開けなくていい！！すごい！！
      • Automation
        • 自動化ドキュメント作って手順通り自動実行
          • AutoScalingからEC2のつけ外しなどが簡単にできる
      • Maintenance Window
        • スケジューリング
        • RunCommand
      • PatchManager
        • パッチのルールを定義してパッチ管理
        • ルール例
          • 分類がSecurityで重要度がCriticalのパッチはすぐ適用
          • それ以外はリリース7日後に適用
        • パッチの適用はRunCommandで

考えること

• デグレは検証環境で潰す
  • 検証環境に適用して3日後にリリースとかでもいい
• 正常判断の基準を作る
  • HTTPアクセスが正常とか
    • テストケースがないのに判断するのは無理
• 正常系テスト自動化が理想
• 日和見アップデートもあり
  • パッチ当てて問題がある可能性は1割くらいでは？
  • 復旧できれば岩盤行ける
• パッチ当ててないでインシデント起きたら責任重大！！！！！
  • やらない失敗よりやって失敗

適用例

• AutoScalingからEC2を1台ずつ切り離してパッチ適用して再度付与
  • 全部の台数にやる
• 素敵すぎる・・・！！

運用自動化のススメ

• 運用に丸投げしないで設計する
• マネージドサービス使おう
• 関しやパッチの運用決める
• 設計できたら自動化しよう

よりよい自動化ライフSecurityライフを！！！

感想＆まとめ

大ボリュームの資料で、とても勉強になるセッションでした。 クラスメソッドさんのセッションは本当に勉強になります。 運用設計をきちんと考えてから 仕組みを作るべしという方針を学びました。

私のチームは現在3人しかいないため、開発も運用も全部自分たちです。出来る限り マネージドサービスを使って楽をしたいと考えています。 私はSSM を使ったことがありません。EC 2のパッチ適用だけではなく、自動起動・停止もできそうなので、Lambdaでやっている運用から切り替えたいと思います！

Twitter でもアドバイスをいただきありがとうございました！

EC2の操作ならどちらでも大丈夫ですね！書き方が異なるので、普段からLambdaで使える言語使ってるならそちらもありです！
SSMの場合はEC2周りとかにフォーカスされてるのでコーディング少なくて済む場合も多いのでやりやすい方選んでください！

— けーにー (@ke_ni_) 2019年2月23日