この記事は約12分で読めます。
こんにちは。AWS サポート課の宮崎です。
先日、AWS ジャパン主催のセミナー「Cloud Audit Academy」に参加してきました。 今回はその内容をギュッとまとめて、クラウド監査の考え方のさわりをご紹介します。
AWS の細かなサービスや技術には言及しませんので、これからクラウド監査をする方・受ける方にとって、「クラウド監査ってどう取り組めばいいんだろう」「どういうところが見られるんだろう」と考えるとっかかりになればと思います。
はじめに
Cloud Audit Academy とは
Cloud Audit Academy (CAA) は、アマゾン ウェブ サービス (AWS) のセキュリティ監査ラーニングパスであり、クラウドの規制対象ワークロードの評価に携わる既存および将来の監査、リスク、およびコンプライアンスの専門家のために設計されています。 （中略） Cloud Audit Academy は、リスクベースのアプローチを使用してクラウドのセキュリティを監査するための教育とツールを現役の監査人、およびこれから監査人になるユーザーに提供します。 aws.amazon.com
Cloud Audit Academy の趣旨は上記の通りで、今回は監査法人や金融企業から、クラウド・AWS にはあまり触れたことのない方々が参加されていました。
内容としても、AWS の細かな話というよりは、監査人の注目すべき大まかな観点が重点的に説明されていました。
本記事について
本記事では、クラウド監査にあたり注目すべきポイントについて、Cloud Audit Academy で学んだ知識をいくつかのテーマに分けてまとめます。
冒頭でも述べたように、セミナーの趣旨に則って AWS の細かな話は書きませんので、より深掘りしたい方は記事内でご紹介する AWS 公式ドキュメント等をご参照いただければと思います。
また、私も監査については全くの未経験ですので、未経験ならではの易しい言葉での記載を心がけました。そのため、クラウド監査のとっかかりとしてお役に立てるかもしれません。「新人がクラウド監査のセミナーに行ってきたあとのレポート」を読むような気持ちでご覧いただけますと幸いです。
クラウド監査のポイント
導入
Building Block
まず最初に抑えておきたい大前提が、「Building Block」という考え方です。
Building Block とは、一つ一つのサービスを組み合わせてシステムを作っていくということを意味し、AWS でよく用いられる考え方です。
クラウドにおいては、一つのサービスのみでシステムを構成することはほとんどありません。
監査人はそれを理解し、「何を構成要素としているのか」「何を目的に、どう構成しているのか」を把握することが重要です。
今回ご紹介するポイント
それではここから、クラウド監査において注目すべきポイントについて、以下の 5 つの観点でまとめていきます。
① 責任の境界
② セキュリティとガバナンス
③ ユーザーとアカウントの考え方
④ 構成とネットワーク、ログ記録
⑤ ビジネス継続性
① 責任の境界
そもそも、監査人はなぜ「クラウドのセキュリティ」を改めて考える必要があるのでしょうか？
従来の監査で見てきた IT のセキュリティとは何が違うのでしょうか？
その答えの一つは、従来の IT よりも「提供者側と利用者側の責任境界点が曖昧になっている」点にあると言えます。
従来の IT では、「サーバーの責任はサーバーのメーカー」「そのサーバーで動かしている自前のアプリケーションの責任は自分たち」と、責任の所在は考えやすいものでした。
一方クラウドでは、その責任の線引きが一概にはできません。
例えば AWS においても IaaS 的なサービス、PaaS 的なサービス、SaaS 的なサービス*1が混在しており、サービスによって責任境界点が異なっています。
そのため、クラウド監査においては「責任境界点はどこなのか？」という変動的な観点を常に頭に置く必要があります。
AWS においては「責任共有モデル」というものが定められ、AWS サービスの提供形態に応じて AWS と利用者がお互いにどの範囲の責任を負うのかが明確化されています。
監査人は、この責任境界点をはじめに把握したうえで、監査に取り組むことが重要でしょう。
なお、AWS には「AWS Artifact」という各種コンプライアンスレポートをダウンロードできるサービスがあります。
AWS Artifact では、「SOC2 レポート」という、 AWS の統制環境についての説明と、セキュリティ、可用性、機密性、プライバシーに関する監査についての説明のレポートを取得できます。
AWS がどのようにして責任を果たしているのか、監査の際の参考になるのではないでしょうか。
② セキュリティとガバナンス
「ガードレール型」のセキュリティコントロール
従来のセキュリティコントロールは、「ゲートキーパー型」と呼ばれる形態がよく見られました（ユーザー部門が何かやるたびにガイドラインを確認したり、管理部門がチェックしたり…）。
一方でクラウドにおいては、「ガードレール型」のセキュリティコントロールが講じられるケースが想定されます。
ガードレール型セキュリティコントロールでは、「やってはダメなこと」をあらかじめ決めておき、そのルール内でなら好きにできるようにするという仕組みがとられます。
この仕組みにより、都度チェックをする必要がなくなり、管理部門とユーザー部門双方の負担が軽減され、企画・開発のスピードアップも期待できます。
AWS においては、「サービスコントロールポリシー（SCP）」や「IAM ポリシー」といった機能でガードレールを構成することができます。
監査人は、このような形態のセキュリティコントロールがあることを知ったうえで、自社や監査対象の組織がどのような形態をとっているかを確認する必要があります。
CCoE
また、社内におけるクラウドのガバナンスを向上させる仕組みの一つとして、「CCoE（Cloud Center of Excellence）」というものがあります。
AWS 公式ブログ*2によると、CCoE とは、「クラウドがビジネスにもたらす経済的価値を追求し、会社や組織全体としてこれを享受するための施策を立案／推進するチーム」とのことです（CCoE についての考え方は組織によって多様なので、あくまで一つの考え方として捉えると良いでしょう）。
CCoE では、部門横断でクラウド利用推進のチームを組成し、ナレッジを共有して知識を標準化していきます。
特にクラウドのセキュリティを考えるうえで、セキュリティ担当者が参加することも有効でしょう。幅広い部署の担当者がナレッジを共有することで、「ユーザー部でシャドー IT が発生する･･･」「情シスから、考えたアイデアがセキュリティ的にまずいとよく言われてしまう…」「クラウドが導入されはじめたけど、どうやって監査したら良いのかわからない…」といった問題が解消することが期待されます。
③ ユーザーとアカウントの考え方
クラウドにおけるユーザーとアカウント管理
従来の IT では OS より上のレイヤーのアカウント管理が必要でしたが、クラウド上では、そのクラウド自体のアカウント管理が必要になります。
例えば AWS では、「AWS IAM」と「AWS Account」という AWS 上の認証・認可の管理が必要になります。
これは追加の管理が必要になるという点では面倒な要素にも捉えられますが、これのおかげで AWS 上でのユーザーや環境の管理が楽になるという側面もあります。
また従来の監査では、エビデンスの準備や長時間のヒアリングによってユーザー部署や情シス部署の業務に支障が出てしまうことが往々にしてありましたが、クラウド監査においては、クラウド自体の監査専用ユーザーやアカウントを利用して、監査人が直接確認し、ユーザー部署や情シス部署の仕事を止めずに監査することも可能です。
ぜひ、クラウド監査に取り組む際は、監査のやり方についても従来のものから変えられないか、考えてみてはいかがでしょうか。
AWS の従業員への統制について
「クラウドのデータセンター従業員はいつでもわが社のデータにアクセスできるのではないか？」と不安になる方もいらっしゃるかもしれません。
実際のところ AWS では、従業員は顧客が利用する基盤やその中のデータにアクセスすることは厳しく制限されています。
アクセス権の管理やアクセスログももちろん記録されており、厳格な統制がとられていると言えるでしょう。
また、データを暗号化しておくことで、物理的なデータの持出しへの対策を講じることもできます。
ぜひ、クラウドにおける物理的なデータアクセスへの対策についても、ご参考にしていただければと思います。
④ 構成とネットワーク、ログ記録
構成
クラウドにおけるセキュリティリスクを根本的に低減するためには、「誤った実装を防ぐ」ことが重要です。
手作業で構築すると、人間が操作するので必ずミスが起こります。ゆえに手作業を減らすことで、構成ミスを減らし、セキュリティリスクを低減することができます。
その方法として、「IaC (Infrastructure as Code) 」というものがあります。
IaC は、IT インフラ構築を、コードを用いて自動的に行うことを指します。これにより、しっかりテストしたコードを使って構築すればミスは起きえず、コードの一部を調節することで他の環境でも使いまわすことができます。
AWS では、「AWS CDK」や「AWS CloudFormation」という IaC のサービスが提供されています。
自社の IT インフラが「どのように構築されているのか」という点にも目を向けてみるのも良いでしょう。
ネットワーク
システムがインターネットからアクセスできるかどうかで、セキュリティリスクは大きく変わることは、ご認識の通りだと思います。
クラウドのネットワークは、インターネットからアクセスできる領域（パブリック）とアクセスできない領域（プライベート）に大別できます。
クラウドの構成図は見慣れないアイコンや用語が多くよくわからないかもしれませんが、一つの目印として、インターネットゲートウェイと接続しているリソースはインターネットからアクセスできます。
AWS の構成図においては「Internet Gateway」と書かれた紫色の丸いアイコンを見つけたら、まずはその接続先を注意深く見てみましょう。
ログ記録
構成やネットワークは、ログを記録することで「いつ、誰が構成を変更したのか」「どんな通信が行われたのか」といった情報を記録することが可能です。
ただし、むやみにログを取るだけでは、管理の手間も膨大になり、見るのも億劫になってしまいます。
包括的なログ記録とモニタリングの方針を策定してその目的を明確化することで、「何を取る？」「誰が見る？」「どう使う？」を考慮した、効果的なログの活用が可能になります。
⑤ ビジネス継続性
災害時などのビジネス継続計画の一環として、データセンターを地理的に離れた複数の場所に分けて冗長化する方法があります。
これは、従来の IT では場所代・ハードウェア代等のコストがかさむためハードルが高い方法でしたが、クラウドではその制約がないため、採用しやすくなりました。
AWS においては、「リージョン」や「アベイラビリティゾーン」といった形で、地理的に離れた場所でリソースを保有することが可能です。
冗長化と一言で言っても、待機系の起動状態やバックアップの取り方等に種類があり、SLA（Service Level Agreement）によって取る手段が変わります。
監査で主に見るのは、アプリケーションレベルの SLA です。個々のサービスの SLA に執着するよりは、どのような SLA のサービスを利用し、結果的にアプリケーションレベルの SLA が達成できているのかという観点で、ビジネス継続性を検証しましょう。
おわりに
ここまで、クラウド監査において監査人が注目すべきポイントについて、記載してきました。
このような内容を踏まえて、監査において心に留めておくべきことは、「監査は対話である」ということです。
例えば、一見するとリスクが高そうな構成でも、ビジネス上の理由であえてそうしていることもあるでしょう。しかし、それを説明として引き出せなければ、一般的な指摘をせざるを得ない・それに従わざるを得ないという状況になりかねません。
そうならないために、監査人と被監査者が対話できる必要があります。
監査という言葉のイメージからはネガティブな感情を抱きがちではありますが、問題箇所の指摘自体が監査の目的ではなく、指摘を含めた対話を通して、監査対象の組織やシステムを改善していくことが目的です。
そして対話をするためには、「なぜこの形にするのか」を考えて実装し、それを文書として残しておくことが重要です。
以上、私が Cloud Audit Academy で学んだことのまとめでした。 この記事が、読んでくださった皆さんにとって、クラウド監査の「対話」に意識を向けるきっかけとなれば幸いです。
*1:クラウドコンピューティングのタイプ | AWS
https://aws.amazon.com/jp/types-of-cloud-computing/
*2:今から始める CCoE、3 つの環境条件と 3 つの心構えとは | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/how-to-get-started-your-own-ccoe/
宮崎 拓実(執筆記事の一覧)
金融系企業から研修生として出向中です。 AWSサポート課所属。
