はじめに
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)などに設定されていたらエラーを検知する
- 0.0.0.0/0
- 耐障害性
- サービスの制限
- ビジネスサポートで全機能使用可能
- 24/365対応可能
- 電話・チャットも可能
- SUMMIT でおためしキャンペーン中とのこと
まとめ
AWSサポートの現場でよくある事例を紹介していただきました。いずれも難しい対策ではありませんが、だからこそ対応していなかった際の影響が甚大です。当たり前と言われることを、ちゃんとやることは、実は難しいと考えています。
一度漏洩した情報はあとから秘匿できない という考えを常に意識しつつ、このセッションの内容は全て実践する必要があると感じました。
また、AWSビジネスサポートは7/11までキャンペーン中とのことなので、私も試してみたいと思います!