ハイブリッド・クラウド・アーキテクチャー Part 3: セキュリティー

こんにちはIBMのデベロッパー・アドボケイト、Sai Vennamです。本日はハイブリッド・クラウド・アーキテクチャーのセキュリティーについてお話しします。これはハイブリッド・クラウド・アーキテクチャー・シリーズのパート3です。

セキュリティーはさまざまなニュアンスを持つトピックですが、説明するためにまずはNorth-Southネットワーク・トラフィックと、East-Westネットワーク・トラフィックという2つの主要概念についてお話しします。

私は今日出社したとき、かばんから身分証を取り出して、スキャンしなければビルの中に入れませんでした。これは境界セキュリティーと呼ばれ、North-Southネットワーク・トラフィックの中核となる部分です。North-Southは基本的にエンド・ユーザー・アプリケーションからデータセンターや、パブリックまたはプライベート・クラウド環境に送信されるトラフィックを指します。少し戻ってこちらの説明をしたいと思います

[North-Southのネットワーク・フロー]

オンプレミス上でのモノリス

前の動画でお話ししましたが、これはStock Traderのモノリスで、オンプレミスのデータセンターに配置されています。ここにはいくつかのサービスが含まれています。クラウドとの通信に利用するものや、データ・ストアなどです。

alt

先程触れた境界セキュリティーは、データセンターには、あって当たり前と考えられています。データセンターの前面には、ファイアウォールが設置されていて、データセンターと、そこで実行されているアプリケーションやワークロード用のプライベート・ネットワークを提供しています。

alt

これによって、モノリシック・アプリケーションを操作する際に、セキュリティーを確保しやすくなりましたが、セキュリティーの責任をエンタープライズ・アプリケーション開発者に負わせることになりました。

これらのエンドポイントを保護するために重要な点は、モノリスで公開されるすべての機能、APIエンドポイントのセキュリティーを確保することでした。そのためにAPIゲートウェイなどを利用していました。オンプレミス・アプリケーションの前面には、ゲートウェイが設置され、フロントエンドがそのアプリケーションを提供するために必要な主要機能が公開されています。

alt

おそらくモバイル・アプリの場合も同じです。オンプレミス側ではこのように、North-Southネットワーク・トラフィックのセキュリティーが確保されています。

プライベート・クラウド

では少し方向を変えてパブリック・クラウド側、できればプライベート・クラウドについても考えてみましょう。ここにあるさまざまなコンポーネントについては、後ほどお話ししますが、まずはこの部分から見ていきましょう。

これはKubernetesワーカーです。Kubernetesワーカーには、Stock Traderアプリケーションの提供に必要ないくつかのサービスが含まれていると考えられます。モバイルかWebアプリケーションかは問いません。複数のサービスがあり、相互に対話できます。

alt

では、エンド・ユーザーがそのアプリケーションにアクセスするとどうなるでしょうか?エンド・ユーザーは使用可能になったエンドポイントにアクセスする必要があります。ユーザーはそこからパブリック・クラウドに入ります。このレイヤーにはサービス妨害からの保護や、クラウド・プロバイダーが提供するその他の機能が備わっており、要求を認証したり、それが安全な方法で送信されていることを確認したりします。

alt

次に、要求がKubernetesワーカー・ノードに転送されます。ここにはKubernetesの機能が公開されています。このレベルにはエンドポイントを保護するためのオプションがいくつかあります。

alt

セキュリティー・ポリシーの設定方法

Kubernetesワーカーで実行されている。この最初のマイクロサービスにアクセスするとしましょう。2通りの方法でセキュリティー・ポリシーを設定できます。1つ目はIPやポートを扱うことで知られるレイヤー3です。ここでネットワーク・インターフェースのポリシーを設定できます。CalicoやネイティブのKubernetes APIのポリシーを使用します。こちらではレイヤー3のセキュリティー・レベルを指定します。

alt

もう1つのオプションはIstioなどを使用する方法です。レイヤー7のネットワーク・ポリシーやルーティングを指定してセキュリティーを確保します。

alt

この2つの機能を合わせると、レイヤー3から7までのすべての層でネットワーク・セキュリティー・ポリシーに対応できます。着信した要求はポリシーへの準拠が確認されるとワーカーに転送され、サービスにアクセスできます。

これが入口のアプリケーション・フローです。出口の呼び出しでサービスが外部要求を実行する場合も、レイヤー3から7の全層でIstioやCalicoを使用した同様の設定が可能です。

これがNorth-Southトラフィックの入口と出口であり、クライアント、データセンター、およびパブリックまたは、プライベート・クラウド環境における通信です。以上がNorth-Southのネットワーク・フローです。

alt

[East-Westネットワーク・トラフィック]

次はEast-Westについて見ていきましょう。East-Westは、オンプレミスまたは、パブリック/プライベート・データ・クラウド環境で実行されるサービス間の通信です。

alt

セグメンテーション

East-Westの場合、先程の例えに戻ると、私はビルに入るために身分証を提示しました。これでビルには入れますが、毎日勤務している階に行くにはもう一度身分証が必要になります。それが3階だとすると私は3階まで上ってもう一度、身分証をスキャンしなければなりません。4階に行こうとしても、私は設計チームの一員ではないので、入室を許可されません。

これはセグメンテーションと呼ばれる概念を表しています。ビル、つまりアプリケーション・インフラストラクチャーやパブリック・クラウド環境では、相互対話のときにユーザー、管理者、プロセスがアクセスできるセグメントをそれぞれ作成します。

マイクロセグメンテーション

このレベル、つまりお客様のKubernetes環境では、これをマイクロセグメンテーションと呼びます。お客様が管理する環境では、マイクロサービス間でやり取りされるすべての要求に対し、Istioなどを使用してTLSを設定します。

alt

暗号化

暗号化で重要な点の1つは、要求をできる限り早く暗号化し、できる限り後で復号することです。

従来のKubernetesマイクロサービス・アーキテクチャーでは、できる限り早い段階ですべての要求を暗号化します。ただしこれはマイクロサービス間のアーキテクチャーの場合です。モノリスではこれらの点を考慮する必要はありませんでした。

既に述べたようにモノリスでは、ソフトウェア・ベースの呼び出しであるRPC(リモート・プロシージャー・コール)を使用するので、ネットワーク通信の要件は除外されます。したがってTLSを使用する必要はありません。ただし、データベースに対して実行されるネットワーク呼び出しはTLSで保護します。

[クラウド管理側の概念]

マスター・ノード

では次に、ここに描かれたクラウドのクラウド管理側の概念についてご説明します。ここにあるのはKubernetesマスター・ノードです。ここで注意すべき点は、マネージドKubernetesサービスを利用する場合、そのマスター・ノードはクラウド・プロバイダーによって管理されるということです。

alt

etcdデータ・ストア

ワーカー・ノードはユーザーが管理しますが、マスター・ノードは完全に管理された状態にあり、アーキテクチャーの非常に重要な部分であるetcdデータ・ストアを保持しています。Kubernetesでは、十分な注意を払ってetcdデータ・ストアを保護する必要があります。

alt

ここにはサービス、デプロイメント、すべてのKubernetes APIリソースに関するあらゆる情報が保管されているからです。etcdの保護はきわめて重要であり、セキュリティー・アーキテクチャーにおける最優先事項です。

3段階のetcd保護プロセス

そのため、クラウド・プロバイダーは、3段階のプロセスでetcdを保護しています。3つのうち1つ目のステップは認証、つまりTLSです。

alt

その次がRBACです。これはKubernetesロール・ベースのアクセス制御を使用したアクセス許可です。

alt

最後のステップはアドミッション・コントローラーです。Kubernetesの概念では、認証と許可の完了後、もう1つのセキュリティー・レベルがあり、API要求が変更・改ざんされていないこと、etcdデータにアクセスするための正しい形式であることが検証されます。

alt

データ返送

こうしてetcdデータへのアクセスが実行され、ワーカー・ノードにデータが返送されます。ワーカー・ノードではアプリケーション・ポッドが情報を要求または転送します。ここにOpenVPNサーバーがあります。クライアントと連携しています。

alt

OpenVPNサーバーによってユーザーは、etcdデータ・ストアにアクセスしKubernetesワーカーにデータを返送することができます。

alt

ワーカー・ノードとマスター・ノードの連携

Kubernetesはこのようにクラウド・プロバイダー・サービスにセットアップされています。このときマスター・ノードは管理下に置かれ、ワーカー・ノードは安全な方法でマスター・ノードと連携でき、資産は常に保護されています。

もう1つの注目点は、etcdデータ・ストアはクラウドのオブジェクト・ストレージ機能でバックアップされるので、最悪の場合でも資産が安全な場所に保存されているということです。

alt

これでNorth-SouthとEast-Westのネットワーク・トラフィックについて説明しました。クライアントから着信するネットワーク・トラフィックと、データセンター、プライベート環境、および、プライベート/パブリック・クラウド環境のサービス間でやり取りされるネットワーク・トラフィックについてお話ししました。

[DevSecOps]

最後に、DevSecOpsと呼ばれる概念について説明します。DevとOpsの間にSecurityが入っていることにお気付きでしょう。DevSecOpsとは、アプリケーション設計の開始当初から、本番に移行するまでの全行程にセキュリティーを組み込む手法です。

alt

セキュリティーの組み込み

本番への移行時に何も問題が生じないようにするには、DevSecOpsを活用する必要があります。間違った方法でアプリケーションを設計し、それに気付いて最初からすべてやり直すようなことはしたくありません。したがって最初の段階からセキュリティーに配慮することが重要です。 クラウド・ベースのKubernetesサービスを利用する場合は、フローのセキュリティー保護を少し簡単にできる方法があります。ここで考慮すべき点は、CIワークフローやDevOpsフローにセキュリティーを組み込んで自動化することです。

プロセスの自動化

例えば、お気に入りのコード・リポジトリーに、アプリケーション・コードやDockerファイルなどを保存しているとします。このプロセスを自動化し、コードを開発している開発者だけがGitリポジトリーにアクセスできるようにします。

alt

署名者の指定

次に、信頼できる署名者を指定します。レジストリーにコードがプッシュされると、署名者はそのコードを信頼できるイメージ、つまりクラウド管理レジストリーで使用可能なコードとして承認し、署名します。そのイメージをレジストリーにプッシュします。

alt

脆弱性アドバイザー

イメージがプッシュされると。脆弱性アドバイザーという機能によってイメージがスキャンされ、基本オペレーティング・システムから使用中のランタイムに至るあらゆる場所で、問題や脆弱性がないか確認されます。脆弱性が検知された場合はユーザーに通知されます。脆弱性評価に合格したら、それを関連付けてイメージをビルドし、Kubernetesに直接プッシュできます。

alt

アドミッション・コントローラー

この段階で、Kubernetesマスターのところで説明したアドミッション・コントローラーを使用して、そのイメージが安全であり脆弱性がないことを再確認できます 。

ライブ・スキャン機能

最後にライブ・スキャン機能を使用して、本番で実行されているイメージをスキャンし、脆弱性がないことを確認できます。このようにDevSecOpsは非常に重要な概念であり、これによってDevOps実施の初期段階からセキュリティーを管理できます。

alt

ハイブリッド・クラウド・アーキテクチャー・シリーズのパート3:セキュリティーをご覧いただきありがとうございました。パート1、パート2をまだご覧になっていない方は、是非そちらもご確認ください。