クラウドによるセキュリティの原則を説明。その構成要素についても解説している。
クラウド的考え方によるメリット
- クラウドの提供する可能性（機能）を余すとこなく活用できる設計
- 12 Factor App
- Cloud Native
- 3 つの R(後述)
- 12 Factor App + PaaSでの稼働(伸縮性 elasticity) = Cloud Native
10.2 環境に格納された構成情報
- アプリケーション可能のための構成情報の管理がセキュリティ的にも重要だが、場合によって複雑になる
- 構成情報をコードに持たせると危険
- コードにアクセスできるすべての人がアクセスできてしまう
- 複数の環境にデプロイする必要が発生すると構成情報ファイル化する
- 構成情報をファイルに記述すると危険
- 監査証跡なしにファイルを読める
- ファイルにアクセスできる人がすべてアクセスできる
- コードを外部の開発者と共有するときに危険性に気づく
- デプロイ環境に構成情報を配置するとリスクを移転できる
- デプロイ環境から構成情報を取得するように変更することで、構成情報とコードが分離される
- (+)問題はアプリケーションからインフラに移動し、アクセス制御、監査証跡の取得が容易になる
- (-)開発者からインフラ関係者に問題が移動しただけになるため、暗号化などのさらなる仕組みが必要になる
- (-)復号化の仕組みを入れるためにアプリケーションに複雑さが混入する。解決は 3 つの R
- 構成情報をコードに持たせると危険
10.3 stateless アプリケーション
10.4 ログをファイルに残す危険性
- 相反する性質
- システムの悪用につながる機密性の高い情報
- アクセスをよくしたい利活用できる情報
- ログファイルの問題
- 機密性が低い/漏出を防ぐ手段が乏しい/漏出後の追跡が難しい
- だれも編集してないことの保証が難しく完全性に乏しい
- インスタンス破棄、ディスク容量の制限などで可用性が低い
- ログのサービス化
- ログをサーバーのインフラに依存させない
- ログのカテゴリ化、ユーザーの分類によりアクセスを制御、アクセス履歴により監査証跡も取得 = 機密性の担保
- ログの書き込みは信頼できるリソース(アプリケーション)に限定 = 完全性の担保
- サービスのスケールによりインフラのリソース問題を解消 = 可用性
10.5 システム管理プロセス
これ、クラウド関係ないんじゃ…
10.6 サービス検出と負荷分散
- サーバーインスタンスが定期的に生成・破棄されるので必須の技術
