コンテンツの編集
「コンテンツの編集」ボタンをクリックしてコンテンツを編集/追加します。

【 第4章 -Part1 】クラウドネイティブを採用するセキュリティメリット

 昨今、多くの企業が目指すテーマの一つとして「クラウドネイティブアーキテクチャ採用」が挙げられます。この章ではクラウドネイティブアーキテクチャ採用によるセキュリティのメリットに関してご説明いたします。

 最初に、今なぜ多くの企業がクラウドネイティブアーキテクチャ採用が重要課題と考えているのかをここでまとめたいと思います。

グローバルなサービス競争激化への対応

    • サービスのライフサイクルが短くなりより短期間で新サービスの投入が必要になってきている
    • 欧米におけるクラウド利用は日本のそれと3-4年の遅れが指摘されている
    • スタートアップ企業のクラウド利用による大手企業との熾烈な市場競争の台頭
    • 自動化、AI利用の拡大に追従が必須となってきた

国内市場でのアジャイル開発によるリリースサイクル加速化への対応

    • クラウドシフトをIT戦略の一環として差別化を加速
    • リフト&シフトからCNA+マネージド環境利用を思考する企業の増加
    • IT技術者不足に加えクラウド経験者不足を補うため自動化が必須に

セキュリティ面でも優位性を認識

    • CSPの責任共有モデルによるデータセンター周りの管理から開放される
    • シフトレフトをツールによって容易に導入可能
    • クラウドインフラや仮想化レイヤーの統合によりログや設定内容をセキュリティにも自動化、AIを導入することが可能に

 グローバル企業の場合、最初からクラウドネイティブを採用している、スタートアップや強いCTO、CIOなどのリーダーシップによる急速なクラウド移行を成功させている競合との熾烈な戦いに直面しているところも多く、クラウドへの移行は最重要課題となります。また国内においても、クラウド化の流れは本格化してきており、この潮流に追従しなければビジネスチャンスを逃す状況が現実化してきています。そしてこの章のテーマである、セキュリティ面でのクラウドネイティブアーキテクチャ採用メリットも重要です。これらのような理由により企業でのクラウドネイティブアーキテクチャ導入検討が進んでいます。

  目次


クラウドネイティブアーキテクチャとは

 クラウドネイティブアーキテクチャはその名の通り、クラウドを前提としたアーキテクチャを指し、クラウドのメリットを理解するためには参考になる考え方です。Cloud Native Computing Foundation(CNCF)*が発表したクラウドネイティブトライアルマップ**は、クラウドネイティブを理解するのに有効な10項目が提示されています。コンテナ化、CI/CD、オーケストレーション&アプリケーション定義など非常に重要となる項目が含まれています。これらの項目を理解することにより、クラウドによるシステム開発、アプリケーションリリース、可用性の実現方法などクラウド導入・移行のメリットを理解する上で非常に有効なガイドラインとなります。

 一方で多くの企業がデジタルトランスフォーメーションいわゆるDX推進に力を入れています。そしてその進め方の一つとしてクラウドファースト、クラウドネイティブアーキテクチャの導入を掲げている企業が増えてきています。

 それでは今なぜ多くの企業がクラウドネイティブアーキテクチャをDX推進の重要課題と考えているのかを以下にまとめたいと思います。


自動化がキーワード

 もし私に「クラウドネイティブを目指すべき理由を一言で教えて下さい」と聞かれたら「自動化です」と答えます。もちろん質問者の置かれている状況や目指す方向性などを聞かせてもらった上で同じ質問をされれば、もう少し丁寧な回答ができるかもしれません。しかし敢えてこのように雑(?)な聞き方をされたら、こう答えます。もし私がアプリケーション開発エンジニアで毎日コードを書いていたとしたら、コードを書いて、テストして、テストが一通り問題なく完了したらそのまま本番環境にリリースして、アクセスの負荷により自動的にスケールするようにして「全ていい感じ」にしてくれる環境があれば「最高!」と言うでしょう。

 ある日すごいサービスのアイディアが浮かび、それを自分でコーディングして「これはイケる!」「すぐに全世界の人が気に入って毎日使ってくれる!」となったとします。これをこれまでのオンプレ環境でリリースしようとしたら、数億のユーザーが毎日アクセスしてくるようなサービスを提供するための環境と必要な人員を揃えるだけで1年以上かかるかもしれません。もしクラウドネイティブアーキテクチャを完全に理解していて、その環境を既にパブリッククラウド環境に持っていたとしたらどうでしょう。

 コードだけきっちり書いてGitに上げた瞬間からコンテナ環境にデプロイされ、Kubernatesがユーザーからのアクセス数に応じてすべてうまく「いい感じ」で運用してくれるかもしれません。後はパブリッククラウド環境を使った分だけ使用量に応じて利用料がカード引き落としされ、残りはすべて自分の懐に入ってくる。極端な考え方かもしれませんが、それを目指すには今の所
クラウドネイティブアーキテクチャがそれを実現してくれる最有力候補だと私は断言します。コードを書くだけ(これも将来自動化出来るでしょう)でサービスとしてリリースし、その後の対応まですべて自動化することにより最大の収益化をクラウドネイティブで実現できるのです。


セキュリティのシフトレフトとは

 DX推進の目的の一つとしてアジャイル開発の導入・推進によるサービス投入サイクルの短縮と安定したリリースサイクルの実現があります。あらゆるサービスがクラウドで提供され、URLを変えるだけで別のサービスに移行出来る時代に、このテーマは重要です。もし他社のほうが自社のサービスよりも使いやすく、そして安価だとしたらそのサービスに固執する理由はありません。また多くのサービスがサブスクリプションモデルを採用しており、移行も契約だけの話で以前のような初期投資の回収やソフトウェアの移行などもありません。

 そのためSaaSプロバイダは日々お客様からのフィードバックを常に調査、分析してサービスの改善に務めなければなりません。そしてサービス投入サイクル短縮、安定したリリースサイクルの実現を目指し、クラウドネイティブアーキテクチャでも推奨されているコンテナ化、CI/CDなどによる開発環境もクラウドインフラをベースとしたアジャイル開発にシフトしてきています。

 アジャイル開発にはCI/CDにより、コードを書き(もしくは変更追加を行い)、コード実行に必要となる各種ライブラリやパッケージとともにビルトを行いイメージを作成し、テストし、テストが完了したらイメージ(もしくはアーティファクト)をレジストリに登録し、それをオーケストレータが本番環境にデプロイし、その後の利用状況によりコンテナの追加、削除などの運用までの一連の作業の各所にセキュリティチェックを統合する必要があります。

 これまでのセキュリティのための検査、チェックは運用後の環境に対して行われてきました。先にも説明した、ファイアウォールやWAFなどでインターネットとの境界を監視する境界型防御がその良い例です。しかし開発からデプロイまでCI/CDで自動化することにより、この運用後の境界チェックだけでなく、コンテナランライムの脆弱性、承認されたコンテナのみのデプロイ、マイクロアプリケーション間の通信の監視、Kubernetesなどのコンテナオーケストレーションシステムでの無制限の特権アクセスの利用や異なる機密度レベルのワークロードの混在、レジストリ内の脆弱性のあるイメージのチェック、コードビルド時の定義ファイル内の脆弱性チェック、コード内の脆弱性、危険なコードなどのチェックなど、最終的にはコードを書く時点、つまり可能な限り早い段階からセキュリティチェックを入れるといった概念が「セキュリティのシフトレフト」となります。そしてその作業は人手によるマニュアル作業ではなく、可能な限りツールなどによる自動化が重要です。コンテナおよびCI/CDに関しては【インデックス】にて別途説明しているので、そちらも参考にしてください。


公開ガイドライン(CISベンチマーク)を参考にする

 それではセキュリティのシフトレフトで必要となる、パブリッククラウド特有のセキュリティ監査項目はどのように設定すればいいでしょうか。初めからクラウドセキュリティに知見のあるエンジニアが社内にいれば、1から監査項目を考え、チェックリストを作成することは可能です。しかし殆どの場合、既に監査経験のあるプロが作成したガイドラインを参考にして、自社のセキュリティ要件にあったリストを作成するほうが簡単です。

 例えば米国CIS(Center for Internet Security)が発行しているCIS Controls(シーアイエス コントロール)はクラウドを含む、オンプレなどにも適用が可能なインターネット情報セキュリティに対する、基本的な対応がまとめられたガイドラインなどを参考にするといったのも一つの方法です。主にネットワークに関連した一般的なサイバー攻撃を軽減するための18の項目が優先度付きで解説されているため、一般的なサイバー攻撃に対する基本的な指標として有効です。それに対してCISベンチマークには更にOSやオープンソース、さらにAWS、GCPなどの各パブリッククラウドプラットフォーム毎に詳細なセキュリティ対策の実装まで含んだガイドラインとなっています。もし採用するCSPが決まっている場合、こちらのガイドラインを参考にしてもいいかもしれません。以下はCIS Google Cloud Platform Foundation Benchmarkで推奨されているセキュリティ項目の一部です。

項目要約(一部抜粋)
1.IDとアクセス管理
  • すべのサービスアカウント以外へのMFA有効化
  • すべての管理者アカウントへのMFA有効化
  • サービスアカウントに管理者権限が付与されていない
  • サービスアカウントに対するユーザー管理・外部キーが90日以内にローテションされているか
  • Cloud KMS Cryptoキー・KMS暗号化キーが匿名もしくは外部からアクセス出来ないようなっているか
  • APIキーが特定のホストおよびアプリからのみ利用可能になっている
  • APIキーが90日毎にローテションされているか
  • その他全15項目

2. ロギングとモニタリング

  • Cloud Audit Loggingはすべてのサービス、すべてのプロジェクト内のユーザーに正しくコンフィグレーションされている
  • Bucket Lockによりログバケットに保持ポリシーが設定されている
  • 監査コンフィグ変更、カスタムロール変更、VPCネットワークファイアウォールなどに対しログメトリックフィルターが設定されている
  • その他全12項目

3. ネットワーキング

  • プロジェクトに対してデフォルトネットワークが設定されていない
  • Cloud DNSにDNSSECが有効化されている
  • SSH、RDPへのインターネットからのアクセスが制限されている
  • IAP背後のインスタンスに設定したファイアウォールルールがGoogle Cloud Loadbalancerからのヘルスチェックとプロキシアドレスからのみの通信を許可している
  • その他全10項目

4. 仮想マシン

  • インスタンスにデフォルトサービスアカウントがコンフィグレーションされていない
  • インスタンスにすべてのCloud APIへのフルアクセスが設定されたサービスアカウントがコンフィグレーションされていない
  • OSログインがプロジェクトに対して有効化されている
  • コンピュータインスタンスにShielded VMが有効化されている
  • IPフォーワーディングがインスタンスに設定されていない
  • コンピュータインスタンスにパブリックIPがアタッチされていない
  • App Engineにhttpsコネクションを有効化している
  • その他全11項目

5. ストレージ

  • Cloudストレージバケットが匿名もしくは外部からアクセス出来ないようなっているか
  • Cloudストレージバケットがuniform bucket-levelアクセスが有効化されている

6. クラウドSQLデータベースサービス

  • MySQLデータベース
    • MySQLデータベースインスタンスに管理者見解により誰でも接続できないようになっているか
    • ’skip_show_database’データベースフラグがCloud SQL Mysqlインスタンスに対して’on’に設定してあるか
    • ’local_infile’データベースフラグがCloud SQL Mysqlインスタンスに対して’off’に設定してあるか
  • PostgreSQLデータベース
    • ’log_checkpoints’データベースフラグがCloud SQL PostgreSQLインスタンスに対して’on’に設定してあるか
    • ’log_error_verbosity ’データベースフラグがCloud SQL Mysql PostgreSQLインスタンスに対して’on’に設定してあるか
    • ’log_checkpoints’データベースフラグがCloud SQL Mysql PostgreSQLインスタンスに対して’on’に設定してあるか
    • その他全16項目
  • SQLサーバー
    • ’External scripts enabled’データベースフラグがCloud SQL SQLサーバーインスタンスに対して’off’に設定してあるか
    • ’Cross db ownership chaining’データベースフラグがCloud SQL SQLサーバーインスタンスに対して’off’に設定してあるか
    • ’Remote access’データベースフラグがCloud SQL SQLサーバーインスタンスに対して’off’に設定してあるか
    • その他全7項目

7. BigQuery

  • BigQueryデータセットが匿名もしくは外部からアクセス出来ないようなっているか
  • すべてのBigQueryテーブルがCMEK(Customer-managed encryption key)で暗号化されている
  • デフォルトCMEKがすべててのBigQueryデータセットに対して特定されているか


Appendix

  • Recommendation Summary Table
  • Change History 

 MFAの有効化やデフォルトの各種設定チェックなどの一般的なセキュリティ確認項目だけでなく、各CSP毎に固有のサービス名称、パラメータ名など非常に詳細なチェック項目までが具体的にどのような値になっていなければいけないかなどが記述されています。もちろんこれ以外に案件個別、企業個別のガイドラインも必要ではありますが、このような項目を何もないところから列挙するのは難しいため、ある程度の雛形となるこのような各CSP向けのテンプレートとして非常に有効です。

Follow me!

PAGE TOP