AWSセキュリティ対策の全体像｜責任共有モデルと最低限やるべき10項目【2026年版】
「AWSは世界中の大企業が使っているのだから、載せておけば安全だろう」——この認識のまま運用しているシステムは、実はかなり多く存在します。しかし現実に起きているクラウド上の情報漏えいは、AWSのデータセンターが破られて起きたものではありません。そのほとんどが、利用者側の設定ミスによるものです。
AWSのセキュリティは、AWSと利用者で守る範囲がはっきり分かれています。この境界線を知らないまま使うと、「誰も守っていない領域」がそのまま穴になります。
本記事では、AWSセキュリティの責任範囲の切り分け方と、最低限やるべき10項目のチェックリスト、目的別のサービス選定、費用の考え方までを、情シス担当者の目線で整理します。
目次
想定読者
本記事は、次のような方を想定しています。
- AWSを導入したが、セキュリティ設定が十分なのか判断できない情シス担当者
- 「AWSだから安全」と言われて、そのまま運用してしまっている方
- AWSのセキュリティサービスが多すぎて、どれを入れるべきか決められない方
- 経営層や監査部門に、自社のクラウドセキュリティ状況を説明する必要がある方
AWSセキュリティとは何か：事故の大半は「利用者側の設定」で起きる
AWSセキュリティとは、AWSが守る範囲と自社が守る範囲を責任共有モデルに沿って切り分け、自社側の領域を設計・運用することを指します。AWSが提供するセキュリティサービスを導入すること自体が目的ではありません。
ここを取り違えると、次のような事態が起こります。
AWSのデータセンターは、物理的な入退室管理、ハードウェアの保護、ハイパーバイザーの堅牢化まで、自社で構築するよりはるかに高い水準で守られています。第三者認証も多数取得しています。ここは信頼して構いません。
しかし、その上に自社が何をどう置くかは、完全に利用者の責任です。実際に報道されるクラウド関連の情報漏えいを見ると、原因はほぼ次の類型に収まります。
- ストレージの公開設定ミス：S3バケットを「パブリック読み取り可」にしたまま、顧客データを置いていた
- ネットワークの全開放：セキュリティグループで、SSH（22番）やRDP（3389番）を
0.0.0.0/0（全世界からのアクセス許可）のまま運用していた - 認証情報の漏えい：アクセスキーをソースコードに直書きし、GitHubの公開リポジトリにコミットしてしまった
- ログを取っていない：侵入されたこと自体に気づけず、被害範囲も特定できなかった
いずれも、AWS側の不備ではありません。AWSの機能を使って防げたのに、設定していなかったという話です。逆に言えば、やるべきことは決まっており、対策可能だということでもあります。
責任共有モデル：AWSが守る範囲と自社が守る範囲
AWSセキュリティを理解する出発点が、AWSが公式に定義している責任共有モデル（Shared Responsibility Model）です。考え方はシンプルで、次の2つに分かれます。
| 区分 | 責任者 | 対象範囲 |
|---|---|---|
| クラウドのセキュリティ | AWS | データセンターの物理セキュリティ、サーバー・ストレージ・ネットワーク機器などのハードウェア、仮想化基盤、マネージドサービスの基盤ソフトウェア |
| クラウドにおけるセキュリティ | 利用者（自社） | データそのもの、アクセス権限（IAM）、ネットワーク設定、OS・ミドルウェア・アプリケーションの脆弱性対応、暗号化の設定、ログの取得と監視 |
覚え方としては、「箱はAWSが守る。箱の中に入れたものと、その鍵の管理は自社が守る」と理解すると実務に落としやすくなります。
使うサービスによって、境界線は動く
注意が必要なのは、この境界線は固定ではなく、利用するサービスの種類によって動くという点です。
| サービス種別 | 例 | OS・ミドルウェアの管理 | 自社の責任範囲 |
|---|---|---|---|
| IaaS | EC2 | 自社 | OSのパッチ適用、ミドルウェアの脆弱性対応、ウイルス対策まで自社。責任範囲が最も広い |
| マネージドサービス | RDS、S3、Lambda | AWS | OS層はAWSが管理。自社はアクセス権限・暗号化・公開設定に集中する |
つまり、EC2を多用する構成ほど、自社が背負う運用負荷は大きくなります。「マネージドサービスに寄せるとセキュリティ運用が楽になる」というのは、責任分界点が自社側からAWS側に移るためです。設計段階でこの点を意識すると、後々の運用コストが大きく変わります。
一方で、マネージドサービスに寄せてもアクセス権限と公開設定の責任は必ず自社に残ります。S3の情報漏えいがなくならないのは、まさにここが原因です。
AWSセキュリティで最低限やるべき10項目
責任範囲が整理できたところで、自社側で必ず押さえるべき項目を10点に絞って挙げます。まずはこの範囲を埋めることを推奨します。
ID・権限の管理
- ルートユーザーを日常利用しない：ルートアカウントは請求情報の変更など、どうしても必要な場面以外では使いません。アクセスキーは発行せず、作成済みなら削除します。
- すべての利用者にMFA（多要素認証）を設定する：特にルートユーザーと管理者権限を持つIAMユーザーには必須です。パスワード漏えい時の最後の砦になります。
- 最小権限の原則を徹底する：「とりあえず管理者権限」を配らず、業務に必要な権限だけを付与します。IAMユーザーを個別に作るより、IAM Identity Center（旧AWS SSO）で一元管理するほうが、退職者の権限削除漏れを防げます。
- アクセスキーをコードに書かない：EC2やLambdaにはIAMロールを割り当てて、キー自体を持たせない構成にします。どうしても必要な認証情報はSecrets Managerで管理します。
ネットワークの防御
- セキュリティグループを絞る：SSH・RDPの
0.0.0.0/0開放は即座に廃止します。管理接続は、社内固定IPからの許可、あるいはSession Manager経由での接続に切り替えます。 - 公開する必要のないリソースをプライベートサブネットに置く：データベースはインターネットから直接到達できない場所に配置するのが原則です。
データの保護
- 保存データを暗号化する：S3・RDS・EBSはいずれも暗号化を有効にできます。KMSを使えば鍵の管理も一元化できます。デフォルトで有効にしておき、例外を作らない運用が安全です。
- S3のパブリックアクセスをアカウント単位でブロックする：バケットごとの設定に頼らず、アカウント全体でパブリックアクセスを禁止する設定を入れます。事故の確率を構造的に下げられます。
ログと検知
- CloudTrailを全リージョンで有効にし、ログを保全する：誰がいつ何をしたかの記録です。インシデント発生時、これが無いと調査そのものが成立しません。 取得したログは削除・改ざんされないよう、別アカウントや専用バケットに保管します。
- GuardDutyを有効にする：不審な通信やアクセスパターンを自動検知するサービスです。設定は数クリックで完了し、専門の運用要員がいない組織ほど費用対効果が高くなります。
この10項目は、特別な体制や高額な投資を必要としません。1〜8は追加費用がほぼ発生せず、設定変更だけで完了します。にもかかわらず、実際の事故の多くはこの範囲の抜けから発生しています。
AWSのセキュリティ設定が今のままで十分か不安な方は、c3index にお気軽にご相談ください。
目的別に選ぶAWSセキュリティサービス早見表
AWSのセキュリティサービスは数が多く、「全部入れるべきか」と悩みがちです。結論から言えば、全部は要りません。目的から逆算して選びます。
| 目的 | サービス | 位置づけ |
|---|---|---|
| 権限を管理したい | IAM / IAM Identity Center | 必須。すべての土台 |
| 認証情報を安全に保管したい | Secrets Manager | パスワード・APIキーを持つなら必須 |
| 操作ログを記録したい | CloudTrail | 必須。監査・調査の前提 |
| 脅威を自動検知したい | GuardDuty | 優先度高。有効化するだけで機能する |
| 設定ミスを見張りたい | AWS Config / Security Hub | 設定の逸脱を継続的にチェックする |
| Webアプリを攻撃から守りたい | AWS WAF | 公開Webサイト・Webアプリがあるなら検討 |
| 大規模DDoSに備えたい | Shield Advanced | 高額。可用性が売上に直結する場合のみ |
| データを暗号化したい | KMS | 鍵管理の標準。基本的に有効化する |
| 脆弱性をスキャンしたい | Inspector | EC2・コンテナを使うなら価値が高い |
| 個人情報の置き場所を把握したい | Macie | S3に機微情報を保管しているなら検討 |
まず着手すべきは、IAM・CloudTrail・GuardDuty・KMSの4つです。この4つは規模を問わず有効で、導入負荷も低く抑えられます。Security Hub や Config は、運用体制が整ってから段階的に追加するので間に合います。
なお、EC2中心の構成であれば、OS層のウイルス対策やパッチ管理も自社の責任範囲に含まれます。Inspectorで脆弱性を可視化しつつ、パッチ適用の運用ルールを決めておく必要があります。
AWSセキュリティにかかる費用の考え方
「セキュリティ強化＝高額投資」というイメージがありますが、AWSの場合は費用のかからない対策から着手できるのが利点です。
追加費用がほぼ発生しないもの
IAM、セキュリティグループ、S3のパブリックアクセスブロック、各種暗号化の有効化、CloudTrailの基本的な管理イベント記録は、いずれもサービス利用料としてはほぼ発生しません（ログ保管先のS3ストレージ料金など、わずかな費用は生じます）。
前章のチェックリスト10項目のうち、大半がこの領域に該当します。つまり、AWSセキュリティの基礎固めは、ほぼ人件費だけで完了します。
従量課金で費用が発生するもの
GuardDuty、AWS WAF、Security Hub、Inspector、Macie などは、分析するログ量やリクエスト数に応じた従量課金です。小〜中規模の構成であれば、月額数千円〜数万円のレンジに収まるケースが一般的です。
一方、Shield Advanced は月額3,000米ドル程度の固定費がかかる別格のサービスです。サービス停止が直接的な売上損失につながる規模でなければ、標準で有効な Shield Standard で十分なことがほとんどです。
※料金体系は改定される場合があります。導入前にAWSの公式料金ページで最新の条件をご確認ください。
外部委託する場合
セキュリティ設計・診断を外部に依頼する場合は、対象範囲によって費用が変動します。既存環境のアセスメント（設定監査）であれば数十万円規模から、ペネトレーションテストを含む本格的な診断ではそれ以上の規模になります。
自社対応と外部委託の判断基準
すべてを内製する必要も、すべてを外注する必要もありません。判断の目安は次のとおりです。
自社対応で進めやすい領域
- チェックリスト10項目の設定（IAM整理、MFA、セキュリティグループ見直し、暗号化、CloudTrail・GuardDutyの有効化）
- 日々のアラート確認と一次対応
これらは設定作業が中心で、手順も明確です。情シス担当者が1名でも着手できます。
外部委託を検討したい領域
- 現状のアセスメント：自社の設定に何が欠けているのか、客観的に洗い出す作業。内部の人間だけでは「見えていない穴」に気づけません
- インシデント発生時の対応体制：24時間の監視や、実際に侵害された場合の調査は、専門の体制がなければ現実的に回りません
- 監査・認証対応：ISMSや取引先要求への回答など、第三者への説明責任が伴う場面
特に、「今の設定で大丈夫か分からない」という状態そのものがリスクです。まずは現状把握を一度外部の目で行い、その結果を踏まえて内製範囲を決めるのが、費用対効果の高い進め方です。
よくある質問
Q. AWSを使えば、オンプレミスより安全になりますか？
A. 基盤部分は、多くの場合オンプレミスより高い水準になります。 AWSのデータセンターの物理セキュリティや、ハードウェアの保守体制は、自社で同等のものを構築するのは現実的ではありません。ただし、それは「クラウドのセキュリティ」の話です。データやアクセス権限を守る「クラウドにおけるセキュリティ」は自社の責任であり、ここを疎かにすればオンプレミスより危険になり得ます。安全性は移行先ではなく、運用で決まります。
Q. セキュリティ対策は、どこから手をつけるべきですか？
A. ルートユーザーのMFA設定と、セキュリティグループの 0.0.0.0/0 開放の確認です。この2つは今日中に着手でき、費用もかかりません。その後、CloudTrailの有効化とS3のパブリックアクセスブロックへ進めば、代表的な事故類型の大部分をカバーできます。
Q. GuardDutyやSecurity Hubは、必ず入れるべきですか？
A. GuardDutyは強く推奨します。 有効化するだけで脅威検知が始まり、専任の監視要員がいない組織ほど価値があります。一方、Security Hubは検知結果を集約・評価するサービスであり、アラートに対応できる体制があってはじめて意味を持ちます。見る人がいないダッシュボードを増やしても効果は出ないため、体制の整備とセットで検討してください。
Q. 情シスが1人しかいません。現実的に何ができますか？
A. 「人が頑張って監視する」設計を避けることが最重要です。 具体的には、S3のパブリックアクセスをアカウント単位でブロックする、IAMロールを使ってアクセスキー自体をなくす、GuardDutyで自動検知するなど、構造的に事故が起きない状態をつくります。人的リソースが限られているほど、自動化と「そもそもできない設定」に投資すべきです。
「たぶん大丈夫」という状態が、最も危険です。セキュリティ診断で、自社の実際の防御力を確認できます。
まとめ
本記事のポイントをまとめます。
- AWS上の事故の大半は、AWS側の不備ではなく利用者側の設定ミスで起きている
- 責任共有モデルでは、AWSが「クラウドの」セキュリティを、自社が「クラウドにおける」セキュリティを担う。EC2中心の構成ほど自社の責任範囲は広がる
- まずやるべきは10項目。そのうち大半は追加費用なしで、設定変更だけで完了する
- サービスは全部入れる必要はない。IAM・CloudTrail・GuardDuty・KMSの4つから着手する
- 「今の設定で大丈夫か分からない」状態こそがリスク。現状把握を一度外部の目で行うのが近道
AWSは、正しく設定すれば非常に堅牢な基盤です。逆に、設定しなければ守ってくれない領域が明確に存在します。この境界線を把握することが、AWSセキュリティ対策の第一歩になります。
c3index に相談する
c3index は、製造業の基幹システム・保守・クラウド移行を専門とするシステム会社です。 AWSのセキュリティ設定の見直しから、移行設計・運用体制の構築まで、まずはお気軽にお問い合わせください。
