基盤の保護と、自分たちの設定を分ける
- 責任の境界
- AWSと利用者の責任は採用するサービスや構成によって異なります。データの公開範囲、アクセス権、アプリの動作を誰が確認するかを明記します。
- 人のアクセス
- 利用者ごとの役割、追加認証、退職や担当変更時の扱いを整理します。日常作業と強い権限が必要な操作を分けて考えます。
- 処理のアクセス
- アプリや自動処理が必要とする操作を列挙します。ロールや一時的な認証情報の利用を含め、固定の秘密情報を不用意に持たせない構成を検討します。
権限を、操作と対象の組で確認する
| 権限を、操作と対象の組で確認する | 閲覧する担当者 | 更新する担当者 | 自動処理 |
|---|---|---|---|
| 操作の例 | 担当範囲の情報を読む | 合意された項目を変更する | 定めた入力を読み結果を書き込む |
| 対象の境界 | 他の担当や非公開情報を含めない | 無関係な情報や設定まで変えられない | 必要のないデータや管理操作へ広げない |
| 確認する動作 | 見える情報と見えない情報 | 変更できる項目と拒否される項目 | 通常実行と権限不足時の扱い |
許可と拒否の両方を、変更時に確かめる
- 必要な動作を具体例にする
対象データと操作を結び付けて記録します。機能追加のために広い権限を与える場合は、必要性と見直す条件を残します。
- 意図しない操作が拒否されるか試す
正常に動くことに加え、別の対象への読み取りや不要な更新が拒否されることを、検証環境で確かめる計画を立てます。
- 使わなくなった権限を見直す
担当、連携先、アプリの変更に合わせて権限を再確認します。緊急時の変更も通常状態へ戻したかを記録します。
権限の外側にも、データの扱いがある
アクセス権が正しくても、画面への表示、ダウンロード、ログへの記録で情報が広がる場合があります。収集する項目、保管先、表示先、保存期間をつなげて確認します。
通信と保存時の保護、操作履歴、秘密情報の更新方法を別々の項目として整理します。一つの設定を有効にしただけで全体の安全性を達成したと判断せず、想定する利用と運用に沿って確認します。
安全性を確認するときの考え方
AWSを使えば、利用者側のセキュリティ設定は不要ですか。
利用者が担う設定と運用が残ります。サービスごとの責任範囲を確認し、データ、権限、アプリの動作、変更手順を整理する必要があります。
権限を絞ると、障害時に対応できなくなりませんか。
緊急対応で必要な操作と、日常作業の操作を分けて検討します。必要時の権限取得、記録、終了後の見直しを手順に含め、常時広い権限を持つ以外の方法も比較します。