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

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019「備えあれば憂いなし!AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント」のセッションレポートです。
2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。
ご機嫌いかがでしょうか。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

6月14日 13:00-13:40
 備えあれば憂いなし!AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント

セッション概要

  • セッションの背景
    • 本番環境では特に影響が大きいパターン
      • 認識したときには手遅れだった
      • 例 ルートユーザーの認証が流出
      • 例 インスタンスが1台ダウンして全体がダウン
    • 本番に必要な環境を揃えられなかった
      • 侵入テストの申請を忘れたまま
      • インスタンス多数起動しようとしたら上限に達した
    • 情報が少なく迷宮入りした
      • インスタンスを削除したらログも削除された
      • サービスのログ機能を有効にしていなかった
  • 4つのテーマ
    • セキュリティの備え
    • サービスレベルを維持するの備え
    • 本番運用開始時の備え
    • トラブルシューティングの備え
  • セキュリティの備え
    • 一度漏洩した情報は後から秘匿できない
      • 予め備えておく
    • 事例1 ルートユーザーのパスワード流出
      • 管理コンソールに不正ログイン
        • 本番環境への攻撃
        • 仮想通貨のマイニング
      • 万が一の暫定対処
        • パスワードを変更する
        • 作成されたユーザーやIAMアクセスキーを削除/交換する
        • 不正に作成されたリソースを削除する
      • 日常的なタスクにルートユーザー使わない
      • MFAを有効にする
      • ルートユーザーによるアクセスを記録・検知する
    • 事例2 アクセスキーを誤って公開
      • ソースコードにアクセスキーを含めたままリポジトリにアップロード
      • 暫定対処
        • 誤ったコミットを削除
        • アクセスキーの削除/交換する
      • ソースコードにアクセスキーを含めず環境変数を使う
      • 一時的なセキュリティ認証情報を使用
      • GitHubに公開したアクセスキーを検知する仕組みを作ろう
    • 事例3 S3上のファイルを誤って公開
      • 不適切なポリシーを設定してしまい世界中からアクセス可能な状態に
      • S3 ブロックパブリックアクセスを使って防止する
  • サービスレベルを維持する備え
    • 備えておかないとサービス停止したとき、クイックに復旧しサービスレベルを維持するのは困難
    • 事例1 インスタンスダウンによるサービス停止
      • 想定より多いトラフィックによるダウン
      • アプリケーションのバグによるダウン
      • 基盤の障害によるダウン
      • インスタンスを複数用意
        • ELBを使用して負荷分散
        • 問題発生時に異常なインスタンスを切り離す
        • Auto Scaling
    • 事例2 非冗長構成のDBダウンによるサービス停止
      • 冗長構成の採用を推奨
        • 異なるAZにスタンバイインスタンス
      • Auroraを検討する
        • レプリカへフェールオーバー
        • 複数のAZをまたぐボリュームデータのコピー
    • 事例3 DDoSの影響によるWebサイトダウン
      • 発生してから対処は難しい
      • AWS WAF レートベースのルール
        • レート制限を超えたアクセスはブロック
      • AWS Shield Advanced
        • DDoSレスポンスチームと連携
  • 本番運用開始時の備え
    • 上限緩和、侵入テストの手続きに時間がかかる
      • 必要な手続きは余裕をもって進めていく
    • 事例1 上限緩和手続き忘れ
      • 余裕をもって上限緩和の申請
      • オンデマンドキャパシティ予約
      • 長期利用であればゾーンRIを検討
  • トラブルシューティングの備え
    • 重大なトラブルが発生、調査に必要な情報が揃っていないと遡って情報取得は難しい
    • 必要な情報は記録しておくことが重要
    • 事例1 アクセスログの有効化漏れ
      • ALBで特定時間のエラー原因を調査したいがアクセスログを取得していなかった
      • 本番環境で利用中のサービスはログ有効化
    • 事例2 リソース削除時のログ保全忘れ
      • Auto Scalingによってインスタンスが削除されログファイルも削除された
      • Auto Scaling ライフサイクルフックを使う
        • インスタンス削除処理を一時停止しログを回収
      • CloudWatch Agentでログ収集
        • 突然インスタンス停止してもそれまでにログは保全
  • 本番環境に約立つAWSサポート
    • Trusted Advisor
      • アカウント内のリソースを分析して推奨事項を提案
      • 分析される項目は5つ
        • 例 セキュリティの項目
        • アクセス元が 0.0.0.0/0 のセキュリティグループルールを検出
    • AWSサポートプラン
      • ベーシック、開発者、ビジネス、エンタープライズ
      • 本番環境ではビジネス、エンタープライズを推奨

所感

AWS上で本番環境を稼働させる前に必ず確認しておきたいポイントでした。
重要なのは「予め備えておく」ということです。
事象が発生してから慌てない、後悔しないためにもしっかり準備しておきたいと再認識しました。

以上、吉井 亮 がお届けしました。