EN

NRIセキュア ブログ

クラウドネイティブ化に伴うセキュリティ課題とその解決策

目次

    クラウド環境におけるセキュリティ対策として企業がやらなければいけないことはなにか。
    企業の情報システム・セキュリティに関わる方であれば、AWS(Amazon Web Services)、GCP(Google Cloud Platform)、Microsoft Azure、いずれのクラウドサービスも聞いたことがある方がほとんどであると思われる。

    一方で、クラウドセキュリティで重要な点はなにか、と聞かれて淀みなく答えられる方は少ないのではないか。実際、当社にもクラウドセキュリティ強化に関してご相談を頂くことが増えてきている。

     

    クラウド、という名前を冠したサービス自体は、筆者が10数年前にITエンジニアとしてのキャリアをスタートした時点でもすでに存在した。なぜ、いまなお、クラウドセキュリティに注目が集まっているのか。ここでは、企業が直面するクラウドセキュリティの課題と、クラウド課題解決のためのアプローチの一例をご紹介する。

     

    新規CTA

    企業が直面するクラウドセキュリティの課題

    重要システムのクラウドネイティブ化

    市場でクラウドサービスが普及してからの歴史は長い。多くの企業において、小~中規模システムや、開発環境でのクラウド活用はすでに浸透している印象があり、クラウド関連技術に携わっている人材も一定数は在籍していると考えてよいだろう。

     

    こうした中、いま多くの企業が主要事業を担う重要システムについても、オンプレ環境からクラウド環境へと移行する検討を進めている。事業の根幹を担う重要システムであるがゆえに、経営層も慎重な検討を進めていると考えられ、クラウドセキュリティについての関心は高い。これまでと同様のセキュリティレベルを維持できるか、維持するためにはどのような対策を実施すればよいか、という関心である。

     

    従来のオンプレミス環境と同様のセキュリティ対策がクラウド環境でも実現できれば、セキュリティについての説明責任は容易に果たせる。だが、どうやらそうではなさそうだ、ということは技術に明るくないない方でも何となく認識されているのではないだろうか。

     

    実際、オンプレミス環境では当たり前のように利用されているアンチウィルスや、改ざん検知などのOSへ展開するエージェント型ソリューションは、後述するPaaSサービスでは利用できない。

    また、オンプレミス環境ではインターネットの出入口を一点に集め、WAF、IDS/IPS、NGFW等のセキュリティソリューションを集約するというアーキテクチャが一般的だが、クラウド環境においては、アーキテクチャの特性上、インターネットの出入口を一点に集約できないことが多く、こうした従来型のアーキテクチャでは十分なセキュリティ対策を実現することは難しい。

    さらには、オンプレミス環境の場合、意識的にインターネットへの疎通経路を用意しなければ、外部への情報漏洩リスクは顕在化しにくいが、パブリッククラウド環境の場合、インターネットを介して利用することが前提になっているため、逆に意識的にインターネットとの接続点を認知し、然るべき対策(Role Based Access Control等)をうたなければ情報漏洩リスクが顕在化しやすい、という特性もある。いま多くの企業はこうした局面を迎えている。


    また、近年のクラウド移行シナリオの傾向として、システム改修をできるだけ回避する、オンプレミス環境からクラウド環境(IaaS)への単純移行ではなく、システム構成を抜本的に見直した上でPaaS(Platform as a Service)やFaaS(Function as a Service)等のよりクラウドネイティブな環境への移行を試みる傾向が強い。

    単純なIaaSへの移行では、クラウド移行によるメリットを十分に享受できないことが多いためだと考えられる。この点、クラウド移行のプロセスを象徴した、『リフト&シフト』という言葉がある。以下にそのプロセスを解説しているが、現在の企業の取り組みとして、DX Readyなシステム改革を目指して、Phase2のシフト期に挑んでいる、という傾向がある。

     

    クラウドネイティブリフト&シフトの移行プロセス

    図 リフト&シフトの移行プロセス(NRIセキュアが作成)

     

    クラウドネイティブな環境への移行にあたっては、システム改修が必要というだけではなく、AWS Lambda、Azure FunctionAppsなど新しい領域の技術が活用されていることもあり、セキュリティ業界でのベストプラクティスも確立しておらず、対象システムのリスク分析や、対策検討が難しいという課題も垣間見える。

    クラウドサービス高度化に伴う責任境界の複雑化

    もう一つ、重要システムのクラウド移行にあたり、企業が見過ごすことのできない課題がある。クラウド環境において、セキュリティインシデントが多発しているということだ 。

    とくに、以下の例のように、秘匿性の高い情報を誤ってインターネットに公開してしまうというケースが後を絶たない。

    • S3の誤公開による情報漏洩
    • Github等の公開リポジトリを介したアクセスキーの漏洩

    クラウドサービスが市場で普及し長い時間が経過し、技術の成熟化も進んでいると想定されるにもかかわらず、なぜクラウド環境におけるセキュリティインシデントが多発しているのか。単純に作業者の経験不足や設定ミス、というのも一要因としてあるだろう。だがその本質は、クラウド関連技術の高度化に伴い、ユーザが対応すべきセキュリティ対策範囲が曖昧になっていることにあると筆者は考える。

     

    この点、クラウドサービス事業者により、責任共有モデルというフレームワークに基づいて、ユーザが対応すべきセキュリティ範囲が解説されていることをご存知の方は多いと思われる

    。例えば、Microsoft は、下図のように、オンプレミス、IaaS、PaaS、SaaSと分類し、それぞれユーザが対応すべき範囲を図解している。

     

    Microsoft Azure責任共有モデル

    Microsoft Azure 責任共有モデル

     

    オンプレミスとIaaSとの比較という観点では、IaaSは物理セキュリティ以外のすべてをユーザが担う、ということが読み取れる。一方で、PaaSについては、OSレイヤーのセキュリティをクラウド事業者が担うということはわかるものの、アプリケーションやネットワークコントロールなどの責任範囲について、当該モデルだけでは正確な理解を得るのは難しいのがお分かりいただけると思う。


    また、AWSでは以下の図のような責任共有モデルを提供されている。AWSでは、責任範囲を以下の3つに分類して、ユーザが対応すべきセキュリティ範囲を定義している。

     

    (1) Infrastructure Service(例:Amazon EC2、Amazon EBS、Amazon VPC)

    AWS責任共有モデル_Insfrastructure Service

    (2) Container Service(例:Amazon RDS)

    AWS責任共有モデル_ Container Services
    (3) Abstracted Service(例:Amazon S3、Amazon Dynamo DB)

    AWS責任共有モデル_Abstracted Services

    図 AWS責任共有モデル(「AWS Security Best Practices」より引用)

     

    各分類の定義を紐解いていくと、(1)Infrastructure Serviceについては、IaaSとほぼ同義と解される。(2)Container Serviceについては、OSレイヤーの管理をAWSが担うAmazon RDS(リレーショナル型マネージドDB)が例に挙げられていることからPaaSと解される。(3)Abstracted Serviceについては、Amazon S3が例に挙げられていることからSaaS、ととらえることもできるが、(3)Abstracted Serviceの中には、Amazon RDSと同様、OSレイヤーをAWSが管理するAmazon DynamoDBも含まれているため、(2)との責任範囲の違いを端的に理解するのは難しい印象がある。


    言葉だけでは理解しにくいと思われるため、以下に記載している具体的なシステム構成をみながら理解の整理を試みたい。以下の図では、公開Webシステムについて、EC2やRDSなどのベーシックなコンポーネントで構成される典型的な構成(パターン①)と、API Gateway、Lambda、RDS、S3等のPaaS/FaaS中心のクラウドネイティブな構成(パターン②)に分けた例を記載している。

     

    AWSを活用した代表的な構成例

    図 公開Webシステムの構成例(NRIセキュアが作成)

     

    パターン①は、典型的な構成ながら、責任共有モデルで分解すると、IaaS/PaaSなどの複数のサービスモデルが複合的に組み合わさって成立している。言い換えれば、一般的なシステム構成はIaaS部分、PaaS部分というようにきれいに線引きされているわけではない。どこまでがIaaS、どこまでがPaaSということを検討することにあまり価値はなく、結局、対象システムにおける脅威を念頭に置いて、セキュリティ対策を考えるしかない、ということが言える。


    パターン②については、様々なサービスがより複雑に組み合わさっていることに加えて、各サービスの機能はバラエティに富み、それぞれPaaSの範囲に収まるのかさえ判別しきれない。


    重要なのは、各サービスがどのような機能を有していて、どのような脅威・リスクを内包しているかを正確に理解した上で、対象となるシステム全体としてのセキュリティ対策を検討することである。

    クラウド課題解決のアプローチの活用

    では、こうしたクラウドセキュリティを取り巻く課題に対して、どのようにアプローチしていけばよいか。昨今のトレンドを踏まえた代表的な施策を以下に紹介する。

    予防施策

    (1) CIS Benchmarksの活用

     

    CIS Benchmarksについては、詳細を後述するが、CISという権威ある団体が発行しているセキュリティベストプラクティス集である。AWS、Azure、GCPといった各クラウドサービスに特化したものが公開されており、クラウド環境構築にあたって最低限実施しておくべき対策について、具体的に言及されているのが特徴だ。

    これをもとに、自社内のクラウドセキュリティガイドラインのインプットとして活用することや、環境構築時のチェックリスト、運用フェーズでの定期チェックリストとしての活用のツールとなるだろう。

     

    (2) IaC(Infrastructure as Code)


    IaCとは、インフラ環境のセキュア設定をコードとして体系的に管理し、クラウド環境におけるセキュリティ設定をテンプレート化することにより、画一的なセキュリティ統制を担保する手法である。

    クラウドサービス提供の代表例では、AWS Cloud Formation、3rd Party提供の代表例では、Ansible、TerraFormなどがあげられる。JSONやYAMLなど、コード定義の記述形式の知識が必要になるため、導入にあたってはある程度の技術力が求められる傾向があり、セキュリティ統制部門だけではなく、システム実装部門と一体となって活用していくことが必要になるだろう。

    検知施策

    (3) CSPM(Cloud Security Posture Management)

     

    CSPMとは、PaaSを含むクラウド環境を対象として、セキュリティに配慮した設定がなされていることを継続的かつ自動で評価し、適切な設定への修正を支援するサービスをいう。

     

    サービスによってカバーする範囲は異なるが、なかには、DevSecOpsのプロセス内にセキュリティスキャンを盛り込むことにより、アプリケーションのコード内にハードコーディングされたクレデンシャル情報や、悪意のあるマルウェアコードを検知する機能を有するものもある。当該サービスを活用することで、前述のクラウドセキュリティ課題解決への強力な支援ツールとなるだろう。


    クラウドサービス提供の代表例では、AWS Config、Azure Security Center、3rd Party提供の代表例では、Paloalto Prisma Cloud、Netskope等があげられる。標準で提供される評価ルールに加えて、企業固有のセキュリティ要件に対応させたカスタマイズルールを設定することができるものもある。

    CIS Benchmarks

    本稿では、紙面の都合上、上記対策のすべてに言及しないが、クラウドセキュリティ強化の第一歩として比較的導入の敷居が低い、CIS Benchmarksについてもう少し解説したい。
    CIS Benchmarksとは、CIS(Center for Internet Security)が開発・更新しているサイバーセキュリティにおけるベストプラクティス集で、AWS、Azure、GCPなどの主要なパブリッククラウドのセキュリティ対策に特化したものから、Kubernetes、Docker等のコンテナサービスや、主要なOSの設定など、カバー範囲は多岐にわたる。


    CISとは、米国のNSA(National Security Agency/国家安全保障局)、DISA(Difense Informaton Systems Agency/国防情報システム局)、NIST(National Institute of Standards and Technology/米国立標準技術研究所)などの米国政府機関と企業、学術機関などが協力して運営するインターネット・セキュリティ標準化団体である。


    当団体は、MS-ISAC(Multi-State Information Sharing & Analysis Center)という、『集中的なサイバー脅威の防止、保護、対応、および回復を通じて、国家、地方、部族、および政府の全体的なサイバーセキュリティの姿勢を改善する』というミッションを掲げた活動の運営も担っており、極めて権威のある団体でもある。

    当社がリスク評価フレームワークとして活用を推進しているCIS Controls(※1)も当団体が管理しており、CIS Benchmarksは、CIS Controlsが要求するセキュリティ標準を満たすための具体的な手法を提供する、という役割も担っている。

     

    【解説】セキュリティ業務の自動化におすすめなガイドライン「CIS Controls」とは?

    今回は例として、AWSのセキュリティ対策に特化した『CIS Amazon Web Services Benchmarks』を紹介する。

    以下は当該Benchmarksに記載されている対策事項一覧である。

     

    表 CIS Amazon Web Services Benchmarksの対策事項一覧(NRIセキュアが翻訳)

    CIS Amazon Web Services Benchmarksの対策事項一覧

    『CIS Amazon Web Services Benchmarks』では、(1)IAM (2)Logging (3)Monitoring (4)Networkingの4カテゴリ、全49項目の対策について言及されており、以下の3点の特色がある。

    1. AWS環境のシステム構成に依らない、AWS環境で共通して行うことを推奨するセキュリティ対策に焦点があてられている
    2. 各対策事項について、2段階のLevel(優先度)を設定しており、企業の成熟度に応じた対策の検討に活用することができる
    3. AWS Security Hub/ AWS Configや、Azure Security Center等の各種クラウドサービス内で提供されているコンプライアンス準拠評価機能のルールにも組み込まれており 、準拠状況の確認を自動化し、継続的に行うことができる

    また、各項目について、該当の対策を実施すべき必要性、確認方法、対策方法が具体的に解説されているため、クラウドセキュリティ対策の検討で悩まれている企業が参考にする指標として活用しやすい内容になっていると筆者は考える。まだご覧になったことがない方は是非一度内容を検討頂くことを推奨する。

    おわりに

    弊社では、『クラウドインフラストラクチャセキュリティ』をテーマとして、クラウド環境のセキュリティリスク評価や、クラウドセキュリティ対策強化などのコンサルティング支援を行っている。

    前述の課題感をもつ企業のご担当者など、もし今回の記事を読んで興味をもたれた方がおられたら、弊社コンサルタントまでお声掛けいただきたい。

     

    CSPM製品活用セミナー ~クラウドの情報漏洩を引き起こす”設定ミス”をいかに無くすか~

    新規CTA

     

     

     

    新規CTA