紙一重の積み重ね

アラフォーのエンジニアがなれる最高の自分を目指して、学んだことをこつこつ情報発信するブログです。

【レポート】D3-02 備えあれば憂いなし!AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント #AWSSummit

f:id:yokoyantech:20190614165438p:plain

はじめに

JAWS Summit Tokyo 20193日目に参加してきました。 今年もコンテナとサーバレスを中心に聞いてきたため、レポートをまとめます。

登壇者

AWS 田島氏

セッションの背景

AWSサポートとして見てきた、 予め備えておけばこんなことには・・・という事例

  • 問題を認識したときには既に手遅れだった
  • 本番運用に必要な環境を揃えられなかった
  • 調査に必要な情報がなく迷宮入りした

問題を認識したときには既に手遅れだった

  • rootユーザの情報が流出してしまった
  • システム構成するインスタンスが1台ダウンして、全体がダウンした

セキュリティとサービスレベルの維持の備えが不十分

本番運用に必要な環境を揃えられなかった

  • 侵入テストの申請を忘れた
  • インスタンスの上限申請忘れた

本番運用を開始する備えが不十分

調査に必要な情報がなく迷宮入りした

  • インスタンスが削除され、ログも消えた
  • 利用しているサービスのログを有効化していなかった

トラブルシューティングの備えが不十分

見えてきた4つのテーマ

  • セキュリティの備え
  • サービスレベル維持の備え
  • 本番運用開始時の備え
  • トラブルシューティングの備え

比較的すぐに実施できるものを紹介

セキュリティの備え

  • 一度漏洩した情報はあとから秘匿できない

rootのパスワード流出

  • すべての操作が可能な状態で悪意ある第三者が管理コンソールに不正ログイン
    • 本番環境への攻撃
    • 仮想通貨のマイニング

暫定対処

  • rootユーザのパスワード変更
  • rootユーザおよびIAMアクセスキーの削除・交換
  • 不正に作成されたリソースは削除
    • cloud trailで判断

備え

  • rootユーザは使用しない
    • 権限を限定したIAMユーザを使う
  • MFAトークンを使う
  • rootユーザによるアクセスを記録・検知する
    • Cloud Trails
    • Cloud Watch

アクセスキーを誤って公開した

  • Gitリポジトリにキーを含めてpushした

暫定対処

  • リポジトリのキーを含むコミットを削除
  • IAMユーザのアクセスキーを削除/交換する

備え

  • コードにアクセスキーは含めない
    • 環境変数を使う
  • 一時的なセキュリティ認証情報を使用する
    • IAM Role

S3上のファイルを誤って公開

  • Bucketpolicyをミスした
  • Publicアクセス可能な状態になっていた

備え

  • S3ブロックパブリックアクセスを使う
    • 全てブロックをオン
    • アカウントもしくはBucket毎に設定可能

サービスレベル維持の備え

  • 備えがない状態で壊れると、即復旧することが難しい
    • 耐障害性を意識する

インスタンスダウンによるサービス停止

  • リソース不足やバグ、基盤障害でダウンして、サービスが停止した

備え

  • インスタンスを複数用意する
  • ELBを使ってTrafficを分散する

非冗長構成DBダウンによるサービス停止

  • DBが停止してサービスも止まった

備え

  • MultiAZの検討
  • Auroraを検討
    • Auroraレプリカへのフェイルオーバ

DDoSの影響によるWebサイト停止

  • DDoS攻撃を受けた

備え

  • AWS WAF
  • AWS Shield Advanced

本番運用開始時の備え

  • 上限緩和、侵入テストの手続きには時間がかかる
    • 誤操作による課金を防ぐため、上限がかかっている
    • 必要な手続きは余裕を持って進める

上限緩和の手続き忘れ

  • 200台必要だったが起動できなかった

備え

  • 上限緩和の申請
  • オンデマンドキャパシティ予約
  • 長期料であればゾーンRIを検討

トラブルシューティングの備え

  • 重大なトラブルが発生したときに、情報が残っていないと調査できない
  • 後で原因調査ができるよう必要な情報は記録・保全しておく

アクセスログの有効化漏れ

  • ALBのログを有効化していなかった

備え

  • VPCフローログ
  • Route53 DNSクエリログ
  • WAFログ
  • Global アクセラレータフローログ
  • S3アクセスログ
  • CoudTrail

リソース削除時のログの保全忘れ

  • AutoScalingによりサーバが削除され、ログも消えた

備え

  • AutoScalingライフサイクルフック
    • インスタンスの削除処理を一時停止しログを回収
  • CloudWatchエージェント
    • CloudWatchLogsへ転送する

本番環境に役立つAWSサポート

  • Trusted Advisor
    • コスト最適化
    • パフォーマンス
    • セキュリティ
      • 0.0.0.0/0
        • 20、3306(MySQL)などに設定されていたらエラーを検知する
    • 耐障害性
    • サービスの制限
  • ビジネスサポートで全機能使用可能
    • 24/365対応可能
    • 電話・チャットも可能
      • SUMMIT でおためしキャンペーン中とのこと

まとめ

AWSサポートの現場でよくある事例を紹介していただきました。いずれも難しい対策ではありませんが、だからこそ対応していなかった際の影響が甚大です。当たり前と言われることを、ちゃんとやることは、実は難しいと考えています。

一度漏洩した情報はあとから秘匿できない という考えを常に意識しつつ、このセッションの内容は全て実践する必要があると感じました。

また、AWSビジネスサポートは7/11までキャンペーン中とのことなので、私も試してみたいと思います!