この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
皆さまがシステムを運用にするあたり、様々な不安を抱えていらっしゃると思います。 そういったよくある「不安」を書き出し、解消するための対策や参考ページなども記載しましたので、本記事をご覧いただいている皆さまには抱えている不安を淡々と潰していただければと思います。
【ケース1】大量のアクセスによる高負荷への不安
近日中に Web サイトの広告を出す予定だが、現状のままで増加するアクセスに対応できるのか不安がある
- 以下のような対策が考えられます
- ELB（Elastic Load Balancing）を使用し、Webサーバー（Amazon EC2）の複数台構成にする
- アクセス数や負荷に応じて自動で Webサーバー（Amazon EC2）の台数を増やす（スケールアウト）、減らす（スケールイン）ために AWS Auto Scaling を使用する
- ELB の暖機申請（予め AWS へ連絡して ELB のキャパシティを増やしてもらう）を行う
- 静的コンテンツは Amazon S3 に置き、Amazon CloudFront でキャッシュさせて Webサーバー（Amazon EC2）へのアクセスを減らす
- Amazon RDS でリードレプリカを作成して負荷を分散する
- Amazon EC2 インスタンスの性能を上げる（スケールアップ）
- Webサイトのトップページやアクセスが集中するページは可能な限り静的な内容とすることで EC2 や RDS の負荷を下げる
【ケース2】悪意のある攻撃への不安
悪意を持った大量アクセスが、運用している Web サイトに向けられた時に対応できるか不安がある
- 以下のような対策が考えられます
- AWS WAF を利用する（ウェブ攻撃に対する保護。送信元のIPや国といった条件で拒否できます）
- AWS Shield を利用する（L3/L4を標的とした攻撃の自動検知・自動緩和）
- Amazon CloudFront を利用して Webサーバー（Amazon EC2）へのアクセスを減らす
- ELB（Elastic Load Balancing）と Webサーバー（Amazon EC2）のスケーリングで対応する
- DNS サーバーを Amazon Route 53 へ移行する
- セキュリティグループで不要なポートやアクセス元を制限する
- 異常を検知・証跡を残すためにCloudFrontやELB等の各種ログを取得する
- 参考ページ
- AWS BlackBelt AWS上でのDDoS対策
【ケース3】AWS IAM のアクセスキー漏洩への不安
普段何気なく使っている AWS IAM だが、運用方法に不安がある
- このような運用はしていませんか？
- どんな権限を与えればいいのかわからないので Administrator 権限を付与した
- 1つの IAM ユーザーを複数人で利用している
- 使っていないはずの IAM ユーザーが残ったままだ
- これら資料をお読みいただき、現在の運用方法に問題が無いか確認しましょう
- IAM のベストプラクティス - AWS Identity and Access Management
- AWS を安全に使うために（IAM のベストプラクティス） ｜ Developers.IO
- アクセスキーやシークレットアクセスキーを記載したソースコードが Git リポジトリから漏洩するといった事例もありましたので、git-secrets の導入も有効です
- AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した ｜ Developers.IO
【ケース4】Amazon S3 からの情報漏洩への不安
Amazon S3 に重要なファイルを置いても大丈夫なのか不安がある
- Amazon S3 の安心ポイント
- 初期状態では外部に公開されていません
- ファイルを暗号化する事が可能です
- バージョン管理ができるので、改ざんされても過去の状態に戻せます
- Amazon S3 を使う上での注意点
- バケットポリシーによりセキュリティの設定を行えますが、間違った設定を行うと公開されてしまいます
- 公開されているかは AWS マネジメントコンソール上で簡単に確認できます
- 参考ページ
- 新しい Amazon S3 暗号化 & セキュリティ機能 | Amazon Web Services ブログ
- アクセスポリシーのオプションを使用するためのガイドライン - Amazon Simple Storage Service
【ケース5】Amazon EC2 のセキュリティリスクへの不安
Amazon EC2 の OS 以上のレイヤーは自分の責任範囲になっているが、管理に不安がある
- Amazon EC2 上で動作している Amazon Linux や Windows のセキュリティアップデートは定期的に公開されています
- AWS Systems Manager Patch Manager を使えば自動でセキュリティ関連の更新パッチを適用する事も可能です
- 参考ページ
- 責任共有モデル – アマゾン ウェブ サービス (AWS)
- Amazon Linux Security Advisories
- AWS Systems Manager Patch Manager - AWS Systems Manager
【ケース6】Amazon EC2 に対する不正アクセスへの不安
Amazon EC2 へ不正侵入されないか不安がある
- 以下のような対策が考えられます
- Amazon EC2 インスタンスはプライベートネットワークに置く
- 正当なアクセスはパブリックネットワークに置いた踏み台サーバーを経由させる
- 踏み台サーバーへのアクセスはセキュリティグループにより特定の IP アドレスだけを許可する
- セキュリティグループにより必要最低限のポートだけを許可する
- 可能であれば特定の IP アドレスや管理下のネットワークからのアクセスだけ許可する
- ログを CloudWatch Logs へ転送し、フィルタ機能を使ってリアルタイムで不正アクセスを監視する
- Amazon Inspector を使って定期的に脆弱性診断を実施する
- Amazon GuardDutyを有効化し、異常検知時に通知されるよう設定する
- サードパーティのアンチマルウェア、IDS/IPS製品を導入する
- 参考ページ
- アーキテクチャ - AWS クラウドでの Linux 踏み台ホスト
- Amazon CloudWatch Logs とは? - Amazon CloudWatch ログ
- Amazon Inspector （自動化されたセキュリティ評価サービス） | AWS
さいごに
いかがでしたでしょうか。 AWS を使っていると感じる不安をいくつか挙げてみましたが、なんとな〜く感じていた漠然とした不安を掘り起こすきっかけになれば幸いです。
不安は対策や正しい考え方を知ることで解消できます。 AWS ではホワイトペーパーを公開しており、安全に使うための方法について提供してくれていますのでそちらも一度ご覧ください。 ホワイトペーパー | AWS
また、クラスメソッドではそういった不安を解消するためのお手伝いをしており、今回ご紹介した対策だけでなく豊富な知見をあなたにお届けします！
AWS環境のセキュリティ自動診断サービス「インサイトウォッチ（insightwatch）」を使うと、より簡単にセキュリティチェックができ、しかも無料ですので是非お試しください。
4
