「AWSで作ってもらったから、セキュリティは開発会社にお任せで大丈夫ですよね」。AWSでシステムを構築した発注者から、こうした確認をよく受けます。
「クラウドの会社が守ってくれているはずだから、うちは何もしなくていいですよね？」
結論からお伝えすると、それは半分だけ正解です。AWS自体の設備やネットワークの安全性はAWSが守っていますが、「誰にどこまでの操作を許すか」「バックアップを取るか」「データを暗号化するか」といった使い方の部分の安全性は、利用者（発注者）側の責任になります。開発会社に運用を委託していても、その委託内容と範囲を発注者が把握し、契約で確認しておく必要があります。
この記事では、AWSのセキュリティが「誰の責任か」という考え方と、発注者が自社で確認すべきポイントを、そのまま使えるチェックリスト・質問例とあわせて解説します。
なぜ「開発会社に任せておけば大丈夫」とは言えないのか
AWSと利用者で責任が分かれている（責任共有モデル）
AWSは、データセンターの物理的な警備やハードウェア、ネットワーク設備、仮想化基盤といった「クラウドそのものの安全性」を担う一方、その上でどう使うか（アカウントへのアクセス権限、OS・ミドルウェアの更新、データの暗号化、ネットワークの設定など）は利用者側の責任とする考え方を公表しています。
📰 出典：AWS「責任共有モデル」
つまり「AWSを使っているから安全」ではなく、AWSという土台の上で、誰がどう設定し運用するかによって安全性が変わるということです。実際に起きているクラウド関連の情報漏えい事故の多くは、AWS自体の欠陥ではなく、アクセス権限の設定ミスや、更新すべきソフトウェアの放置など「使い方」に起因しています。
どこまでが自社の責任かは、使っているサービスの種類でも変わる
同じAWSでも、サーバー（EC2など）を借りて自由に組み立てる使い方と、データベースやファイル置き場（RDS・S3など）のように一部の管理をAWS側が代行してくれる使い方とでは、利用者側の作業範囲が変わります。サーバーを丸ごと借りる形ほど「OSの更新」まで自社（＝委託先の開発会社）の作業になり、AWS側が管理してくれる部分が多いサービスほど利用者の作業は減りますが、その場合でも「誰にアクセス権限を与えるか」「暗号化するかどうかの設定」は必ず利用者側に残ります。開発会社に「今回の構成では、どちらの作業がどこまで発生するか」を確認しておくと、見積もりの作業範囲も理解しやすくなります。
| 使い方のタイプ | 例 | AWSが管理する部分 | 利用者（開発会社）側の作業が残る部分 |
|---|---|---|---|
| サーバーを丸ごと借りる | EC2 | 物理設備・仮想化基盤 | OS・ミドルウェアの更新、ネットワーク設定、権限管理 |
| データベースを部分的に任せる | RDS | OSやデータベース製品自体の保守の一部 | アクセス権限、バックアップ設定の確認、暗号化設定 |
| 処理だけを預ける | Lambda等のサーバーレス | サーバーの管理そのもの | 権限（実行できる範囲）の設定、コードの中身の安全性 |
なお、AWSのアカウント自体を発注者と開発会社のどちらが持つべきかという論点は別に整理しています。あわせて確認しておくと、責任の切り分けがより明確になります。
「開発会社に運用委託」＝「責任も全部委託」ではない
開発会社に保守・運用を委託している場合でも、委託契約で決めた作業範囲の中でしか開発会社は動きません。契約書に「セキュリティパッチの適用」が明記されていなければ、開発会社がそれをやってくれるとは限らないのです。IPAも、中小企業がクラウドサービスを安全に使うためには、事業者（クラウド提供者）と利用者の双方が役割・責任を分担し、必要な対策を実施することが重要だと案内しています。
📰 出典：IPA「中小企業のためのクラウドサービス安全利用の手引き」
「クラウドだから安全」「開発会社に頼んでいるから安心」という思い込みが、確認不足の一番の原因です。
よくある思い込みのパターン
- 「大手のAWSを使っているから、自社で気にすることはない」→ 土台の安全性と使い方の安全性は別物
- 「保守を委託しているから、セキュリティ対応も自動的に含まれている」→ 契約書に明記されていない作業は含まれないのが一般的
- 「一度設定してもらえば、あとはそのままで大丈夫」→ 脆弱性情報や利用状況の変化に応じて、設定や更新は継続的に見直す必要がある
発注者が自社で確認すべき5つのポイント
専門的な設定作業は開発会社に任せてよいものですが、「やっているかどうか」を発注者側が確認する仕組みは自社で持っておく必要があります。
1. 誰がAWSにアクセスできるか（権限管理）
- 開発会社の担当者が個人ごとに分かれたアカウントを使っているか（複数人で1つのIDを使い回していないか）
- 退職・担当交代のときにアクセス権限を止める手順が決まっているか
- 「本番環境に何でもできる権限」を必要以上に多くの人に渡していないか
2. OS・ソフトウェアの更新が続けられているか
サーバーのOSやアプリの部品（フレームワーク・ライブラリ）は、放置すると既知の脆弱性を突かれる対象になります。「誰が」「いつ」「どの範囲を」更新するのかが保守契約に含まれているかを確認しましょう。
3. データの暗号化とバックアップ
- 顧客情報などの重要なデータが、保存時・通信時に暗号化されているか
- バックアップの頻度と保存期間、復元の手順が決まっているか（実際に復元できるかのテストをしたことがあるか）
4. ネットワークの公開範囲
管理画面やデータベースが、必要のない範囲までインターネットに公開されていないか。「動作確認のために一時的に開けた設定が、そのまま残っている」というのはよくある見落としです。
5. 何かあったときの連絡・対応の体制
不正アクセスの兆候や障害が起きたとき、誰が最初に気づき、いつまでに発注者に連絡するのか。連絡先と対応期限があらかじめ契約や運用ルールに書かれているかを確認します。
何から手をつければいいか：小さく確認を始める進め方
いきなり全部を細かく確認しようとすると、専門用語の壁で止まってしまいがちです。次の順番で、開発会社との打ち合わせに少しずつ組み込むと進めやすくなります。
- まずは今回のチェックリストを開発会社に見せて、「今の契約でどこまで含まれているか」を一緒に確認する
- 含まれていない項目のうち、影響が大きいもの（顧客データの暗号化・バックアップの復元確認など）から優先して契約に追加するか相談する
- 半年〜1年に一度など、定期的に同じチェックリストで見直す機会を保守契約の中に組み込む
一度に完璧な体制を作る必要はありません。「確認する仕組みがある」こと自体が、大きな安心材料になります。
発注者がやりがちな失敗
- 「AWSは大手だから安心」で使い方の確認をしない：土台の安全性と、使い方の安全性は別物です
- 保守契約の作業範囲を確認せずに「セキュリティは任せている」と思い込む：契約書に書かれていない作業は、通常は追加費用が必要です
- 担当者の退職時にアカウント整理を忘れる：辞めた人のアクセス権限が残ったままになりやすいポイントです
発注者がやることチェックリスト
- ☐ 保守契約に「セキュリティパッチの適用」が誰の作業として含まれているかを確認した
- ☐ AWSへのアクセス権限が担当者ごとに分かれているか確認した
- ☐ 退職・担当交代時にアクセス権限を止める手順があるか確認した
- ☐ 重要なデータの暗号化とバックアップの状況を確認した
- ☐ 管理画面やデータベースが不要にインターネット公開されていないか確認した
- ☐ 障害・不正アクセス発生時の連絡先と対応期限を確認した
開発会社への質問例
- 「保守契約の中で、AWSのセキュリティ設定やOS・ソフトウェアの更新はどこまで含まれていますか？」
- 「AWSへのアクセス権限は、誰がどこまで持っていますか？担当者が変わった時の手順はありますか？」
- 「重要なデータはどのように暗号化・バックアップされていますか？復元のテストはしていますか？」
- 「不正アクセスや障害が起きた場合、いつまでにどのように連絡をもらえますか？」
- 「AWSの設定内容を、自社が確認できる形で共有してもらえますか？」
まとめ：土台はAWS、使い方の安全は発注者と開発会社の共同責任
AWSのセキュリティは「AWS任せ」でも「開発会社任せ」でもなく、AWSという土台の安全性の上に、権限管理・更新・暗号化・監視といった「使い方」の安全性を、発注者と開発会社が役割分担して守るものです。
大切なのは、専門的な設定を自分で行うことではなく、何が誰の責任として契約に含まれているかを把握し、定期的に確認できる状態にしておくことです。まずは今回のチェックリストを使って、今の保守契約の範囲を開発会社と一緒に確認してみてください。
あわせて読みたい関連記事
