備えあれば憂いなし！AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント
セッションの背景
予め備えておけばこんなことには……といった事例の紹介
本番環境で特に影響の多い 3 パターン
問題認識時には手遅れだった
例
ルートユーザーの認証状が流出してしまった
端的に言ってめっちゃヤバイ
システムを構成するインスタンスが1台ダウンしてシステム前停止した
セキュリティ
サービスレベルの維持
本番運用に必要な環境を揃えられなかった
例
侵入テストの申請を忘れたままテスト実施日を迎えてしまった
インスタンスを多数起動しようとしたら上限に達して失敗した
本番運用に対する準備が不十分
調査に必要な情報がなく迷宮入り
例
インスタンスが削除された際にログファイルも削除されてしまった
ログ機能が有効化されていなかった
トラブルシューティングの備えが不十分
パターンから見えた4つのテーマ
セキュリティの備え
重要な理由
一度漏洩した情報は後から秘匿できない
mazamachi.icon あたりまえ体操
セキュリティについては予め十分に検討・準備しておく必要がある
事例
ルートユーザーのパスワード流出
すべての操作が可能なので当然めっちゃヤバイ
本番環境への攻撃とか仮想通貨のマイニングとか他のサーバーへの攻撃とかされる
暫定対処
ルートユーザーのパスワード変更
ルートユーザーと IAM アクセスキーを削除/交換
不正に作成されたリソースがある場合、削除
備え
ルートユーザーを使用しない
普段は IAM ユーザーを作成して使用
可能な限り必要な権限に限定する
MFA token
ルートユーザーの他要素認証
パスワードだけが流出してもログインされる自体は回避できる
ルートユーザーによるアクセスを記録・検知
万が一流出・ログインされても、普段使ってなければ検知できる
アクセスキーを誤って公開
よくあるパターン
git repository にアクセスキーが残っており第三者に見られる
mazamachi.icon よく見るやつ
暫定対処
コミットを削除
IAM ユーザーのアクセスキーを削除/交換
……前の事例同様の対処も必要
備え
ソースコード中にアクセスキーの情報を含めない
一時的なセキュリティ認証情報を使用
IAM ロールとか
↑の「含めない」のソリューションの一つ
ちなみに、AWS側でも検知しているらしい
S3上のファイルを誤って公開
不適切なポリシーを公開してしまう
対処・備え
S3 ブロックパブリックアクセス機能
既存/新規のパブリックアクセスを防止できる
誤ってパブリックアクセスポリシーを適用してしまうことを防げる
アカウントもしくはバケットごとに設定可能
サービスレベルを維持する備え
重要な理由
予め何も備えていないと復旧が大変
予め阿智障害性を意識して、復旧する仕組みを備えておくことが重要
事例
インスタンスダウンによるサービス停止
リソース不足、アプリケーションのbがう、基盤障害など
備え
インスタンスを複数用意する
ELB を使用してトラフィックを分散する
ヘルスチェックをしてくれるので、問題発生時に異常なインスタンスを自動で切り離してくれる
Auto Scaling を使用する
異常なインスタンスを自動的に置換してくれる
非冗長構成 DB ダウンによるサービス停止
非冗長構成の DB インスタンスがダウンしてサービスが停止してしまった
備え
冗長構成の採用
マルチ AZ 構成によって自動フェイルオーバー/復旧
Amazon Aurora を検討
レプリカが
複数 AZ をまたいでいる
グローバルデータベース
DDoS の影響による Web サイト停止
昔は IP アドレスをもとにブロックすることも出来たが、最近は IP アドレスめっちゃ使われたりして対処もできない
備え
AWS WAF
レートベースのルール
AWS Shield Advanced
DRTと連携
本番運用開始時の備え
重要な理由
上限緩和、侵入テストなどの手続きには時間がかかるものがある
課金のリスクを食い止めるため、デフォルトでは上限が急に上がることはない
→必要な手続きは余裕を持って進めておく
上限緩和の手続き忘れ
200台のインスタンスを起動しようとしたら上限に達した……
備え
上限緩和の申請
事前にオンデマンドキャパシティ予約
長期利用であれば、ゾーン RI （割引あり）を検討
トラブルシューティングの備え
重要な理由
必要な情報が残っていないことにあとから気づいても後から取得するのは困難
再度同じ問題が発生する可能性もある
→ 後で原因調査ができるよう、必要な情報はすべて記録・保全しておく
事例
アクセスログの有効化漏れ
ALBで発生していたエラーの原因を調査したいが、アクセスログを有効化していなかった
備え
本番環境で利用中のサービスのログ機能は有効化しておく
様々なサービスのログ機能
ELB アクセスログ
VPC フローログ
Route 53 DNS クエリログ
AWS WAF ログ
S3 アクセスログ
CloudTrail
データイベント
などなど
リソース削除時のログ保全忘れ
アプリケーションのログから調査しようとしたら AutoScaling によってインスタンスとともにログファイルも消えてしまった
備え
Auto Scaling ライフサイクルフック
インスタンスの削除処理を一時停止し、任意の処理を挟む機能
これを利用してログファイルを外部に送ることも可能
CloudWatch エージェント
平常時yリログを収集し、 Cloud Watch Logs に転送する
本番環境の運用に役立つ AWS サポート
Trusted Advisor
アカウント内のリソースを分析して推奨事項を提案
以下の 5 カテゴリ
コスト最適化
パフォーマンス
セキュリティ
耐障害性
サービスの制限
例：セキュリティ
セキュリティグループの開かれたポートで、80,443 などが開かれていればOKだが、20,21 とかが開いてたらエラー、それ以外だと警告
AWS サポートプラン
本番環境で早急に対応しなければいけない問題が発生した場合は24時間365日の対応が大事なので、ビジネスもしくはエンタープライズサポートプランが推奨