はじめに
セキュリティの勉強をしている中で、ゼロトラストという単語を目にしたので調べてみました。
ゼロトラストとは
例えばオンプレミス環境のネットワークにおいては、社内と外部の境界にファイアウォールなどを設置してセキュリティを守ります。このとき、「信用できる領域」と「信用できない領域」を区別することが前提でした。
しかしクラウドの普及などによって社外からシステムにアクセスする機会が増えたため、アクセス元の場所は意味を成さなくなりました。
ゼロトラストとは、社内を含めた全ての領域を「信用できない領域」とみなして、全ての通信を監視・認証・認可を行うことで安全にシステムを運用することができるという考え方です。
NISTSP800-207ではゼロトラストアーキテクチャにおいての7つの考え方が記載されています。
- 全てのデータソースとコンピューティングサービスをリソースとみなす
- ネットワークの場所に関係なく、すべての通信を保護する
- 企業リソースへのアクセスをセッション単位で付与する
- リソースへのアクセスは、クライアントアイデンティティ、アプリケーション/サービス、リクエストする資産の状態、その他の行動属性や環境属性を含めた動的ポリシーにより決定する
- 全ての資産の整合性とセキュリティ動作を監視し、測定する
- 全てのリソースの認証と許可を行い、アクセスが許可される前に厳格に実施する
- 資産、ネットワークのインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、セキュリティ体制の改善に利用する
AWS 規範ガイダンス
「ゼロトラストの導入: 安全かつ機敏なビジネス変革戦略のための戦略」として、AWSがゼロトラストアーキテクチャ戦略を実施するためのガイダンスを公開しています。
今回はその中の「ゼロトラストの原則を理解する」という項目について取り上げます。
ゼロトラストの原則
検証と認証
例えば社内システムへのアクセスに関して、アクセス元が社内なのか外部なのかはクラウドにおいては関係ありません。
場所や人に関係なく、平等に厳密な検証と認証を実施します。
例
- IAMで多要素認証（MFA）の利用
- 通常のID・パスワードを入力し、認証コードや生体認証を追加で行う多要素認証を設定する
- Cognitoでユーザー認証管理
- 各APIにcognitoのアクセストークンを認証として利用し、アクセストークンに期限を設ける
- Webサイトであればリクエストごとに検証と認証を行う
最小特権アクセス
タスクやリソースごとにきめ細かなアクセス制御を実施することで、よりリソースの独立性とセキュリティを高めてゼロトラストを実現します。
それぞれの役割と責任を明白にし、情報漏洩や不正アクセスを防ぎます。
例
- IAMポリシーによる詳細な権限設定
- IAMロールとIAMユーザーによる権限分け
- 必要な人が必要なリソースにのみアクセスできる状態
マイクロセグメンテーション
ネットワークを細かなセグメンテーションに分割してセキュリティ向上を図る戦略です。
ゼロトラストでは社内外全てを信用しない領域とするため、社内であっても不要な経路は全て排除する必要があります。
複数種類のシステムやデータが同一ネットワーク内に存在するのを避け、不正アクセスの可能性を排除します。
例
- VPCによるネットワークの分離
- サブネットの適切な定義など
- EC2インスタンスごとのセキュリティグループによるアクセス制御
継続的なモニタリングと分析
アクセス者を「信用しない」ということは当然ながら監視が必要ということになります。
ユーザーの行動やネットワークのトラフィックなど、システム内の動きを可視化することがとても重要です。それを実現するためのログの設計とツールが必要になります。
例
- CloudWatchによるリソースのモニタリング
- CloudTrailによるユーザーアクティビティとAPIの使用履歴の追跡
自動化とオートメーション
ゼロトラストに限った話ではないですが、セキュリティイベントに対しては一貫したセキュリティポリシーの中で迅速な対応が求められます。人的ミスも許されません。単純なタスクは自動化することで、我々はより戦略に集中することができます。
例
- Systems Managerによるサーバー操作の自動化
- AWS Config によるリソース設定の監視
- Lambda による任意の処理の自動対応
認可
AWSのガイダンスではここで「認証」と表記されていたのですが、「認可」の方が適している気がして変更しました。
ゼロトラスト戦略ではリソースへのアクセス要求に対し、デバイスの状態と態勢、動作パターン、リソース分類、ネットワーク要因などの追加のコンテキストを考慮した上で明示的に承認をする必要があります。
それらを考慮した上で追加の権限を付与することがある場合、機械学習モデルを使って宣言型ポリシーを動的に補完することもできるそうです。
例
- IAMの条件キーによる詳細な制御
- Resource Access Manager (RAM)によるアカウント間でのリソース共有の制御
- AWS KMSによる暗号化キーのアクセス制御
- Lake Formationによるデータレイク構築・運用とアクセス制御
補足: 上記の「最小特権アクセス」と「認可」の違い
最小特権アクセス では必要最小限なアクセス権限の必要性に焦点を当てていると考えられます。
「不要なアクセス権限は与えないようにしようね」という内容です。
認可 は各リソースへの各アクセス要求に対しての承認判断プロセスに焦点を当てていると考えられます。特に動的な条件でアクセス権限を付与する場合に重要な視点です。
「ちゃんと状況を見て判断してアクセス権限を付与しようね」という内容です。
感想
これまでずっとクラウド環境でしか開発をしたことがなかった私からすると、今回紹介したような実装方法自体にギャップや違和感は一切ありません。
しかしゼロトラストという考え方はそこまで意識したことがなかったので、そういった思想があるんだなということでアクセス制御やログの設計などを今一度見直してみようと思います。
参考
令和７年度情報処理安全確保支援士教科書（著 瀬戸美月 齋藤健一）