Amazon RDSのSQLログをIBM Security Guardiumで可視化してみた（２）
投稿者：林田 誠
こんにちは、今回はAmazon RDS for SQL Serverのデータベース操作ログをIBM Security Guardium(以下、Guardium)を利用して、ログをレポート表示してみたいと思います。
クラウドに移行した場合、データベース監査をどうやって実現するのか悩んでいるかと思います。Guardiumでは、オンプレだけではなくクラウドのDBaaS型のデータベースログをIBM Guardium External S-TAP(以下、External S-TAP)で取得することができます。
どのようにログを取得しているのか仕組みを理解する上でも、実際にAWS上でGuardiumの環境を構築してみました。
前回の記事の続きとなります。
Amazon RDSのSQLログをIBM Security Guardiumで可視化してみた（１）
前回のおさらいです。
構成イメージ
構成イメージは下記となります。
※今回はわかりやすくするためにRDSやGuardium Collectorはシングル構成としています。
確認したいこと
・AWS外部のDBユーザー（※自端末）からAmazon RDS for SQL Server（External S-TAP経由）に対して、SQLを実行します。
・AWS外部のDB監査担当（※自端末）からGuardium Collectorに対して、ブラウザでSQL実行ログのレポートを表示します。
構築の流れ
今回は、（２）のExternal S-TAPのデプロイから続きを実施します。
（１）AWSにGuardium Collectorをデプロイ
（２）Amazon EKSクラスターにExternal S-TAPをデプロイ
（３）DBクライアントからSQL実行レポートを表示
※AWS関連の詳細については省略しています。
（２）Amazon EKSクラスターにExternal S-TAPをデプロイ
（２）- a. Amazon EKSクラスターの作成
External S-TAPが動作するためのAmazon EKSクラスターとワーカーノードを作成します。
EC2上にDockerコンテナを立てて、Dockerコンテナ上でExternal S-TAPを実行することも可能ですが、今回は可用性・耐障害性を考慮してマネージドサービスのAmazon EKSを利用します。
1 作業端末からコマンドが実行できるように事前にツールを導入しておきます。
・AWS Command Line Interface (AWS CLI)
・eksctl コマンドラインユーティリティ
・kubectl
・aws-iam-authenticator
2 EKSを作成するために、Amazon EKS サービスロール、ワーカーノード用IAMロールへ
EKS関連のポリシーをアタッチします。
この後のAWS作業で必要なAWSユーザーを作成して、EKS関連のポリシーをアタッチします。
3 作業端末のターミナルを開き、以下のコマンドを実行してAWS CLIの接続設定をします。
| aws configure |
4 以下のコマンドを実行します。実際にはコマンドは1行となります。
※パラメータは各AWS環境に合わせて設定します。
| eksctl create cluster –name visdp1-gdm-eks1・・・クラスター名 –version 1.21 –nodegroup-name guard-workers ・・・ノードグループ名 –region ap-northeast-1 ・・・リージョン –nodes 2 ・・・ノード数 –nodes-min 1 ・・・最小ノード数 –nodes-max 2 ・・・最大ノード数 –node-type m5d.large ・・・ノードインスタンスタイプ –vpc-public-subnets subnet-aaaaaaaaaaaaa,subnet-bbbbbbbbbbbbb ・・・パブリックサブネット –vpc-private-subnets subnet-ccccccccccccc,subnet-ddddddddddddd ・・・プライベートサブネット –node-private-networking |
5 Amazon EKSのクラスターが作成されていました。
Amazon EKSのEC2ノードが [Availability Zone 1a] と [Availability Zone 1c] の
各アベイラビリティゾーンに作成されています。
6 Guardium CollectorからEKSクラスターにExternal S-TAPを作成する時に使用するトークンを
作成します。下記のコマンドで「admin-service-account.yaml」ファイルを実行します。
| kubectl apply -f admin-service-account.yaml |
| admin-service-account.yaml |
|---|
| apiVersion: v1 kind: ServiceAccount metadata: name: visdp1-gdm-admin・・・任意の名前 namespace: kube-system — apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: visdp1-gdm-admin・・・任意の名前 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: – kind: ServiceAccount name: visdp1-gdm-admin・・・任意の名前 namespace: kube-system |
下記のコマンドで作成したトークン名を取得します。
★トークンは、後でExternal S-TAPをデプロイするときに使用しますのでメモしておきましょう。
| kubectl -n kube-system get secret | Select-String visdp1-gdm-admin |
|
Name: visdp1-gdm-admin-token-dm5d6 Type: kubernetes.io/service-account-token Data |
下記のコマンドでKubernetesクラスターのマスターURLを取得します。
★KubernetesクラスターのマスターURLは、後でExternal S-TAPをデプロイするときに使用しますのでメモしておきましょう。
| kubectl cluster-info |
|
Kubernetes control plane is running at https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.sk1.ap-northeast-1.eks.amazonaws.com To further debug and diagnose cluster problems, use ‘kubectl cluster-info dump’. |
（２）- b. Dockerレジストリ設定
Dockerレジストリから、External S-TAPのDockerイメージを取得するための設定をします。
Amazon ECSにExternal S-TAPのコンテナイメージを登録してそちらから利用することもできますが、今回はDocker Hubから取得します。
1 Docker HubのIDがまだ作成していない場合は、新規作成します。
Dockerのイメージをダウンロード（pull）するには、Docker HubのIDが必要となります。
https://hub.docker.com/signup
GuardiumのDockerイメージはこちらのようです。
https://hub.docker.com/r/ibmcom/guardium_external_s-tap
バージョン毎のタグもあるようです。下記のコマンドでKubernetesクラスターのマスターURLを取得します。
★タグとPullコマンドは、後でExternal S-TAPをデプロイするときに使用しますのでメモしておきましょう。
| docker pull ibmcom/guardium_external_s-tap:v11.3.0.139 |
2 Amazon EKSからDocker レジストリに接続するためのシークレットを作成します。
★シークレット名は、後でExternal S-TAPをデプロイするときに使用しますのでメモしておきましょう。
ユーザ名、パスワードは、先ほど作成したDocker HubのID、パスワードを指定します。
| kubectl create secret docker-registry regcred・・・シークレット名 –docker-server=https://index.docker.io/v1/・・・DockerレジストリのURL –docker-username=xxxxxxx・・・ユーザ名 –docker-password=yyyyyyy・・・パスワード |
ここまででExternal S-TAPをデプロイする準備が整いました。
（２）- c. External S-TAPのデプロイ
1 Guardium CollectorのGUI画面にログインします。
https://(Guardium CollectorのIPアドレス):8443/
ナビゲーションメニューの[管理]-[アクティビティー・モニター]-[外部 S-TAP 制御]を選択します。
2 プラスマークをクリックすると、外部 S-TAP のデプロイの画面が表示されます。
3 Kubernetesタブで、メモしていた値を入力しましょう。
4 Dockerタブも同様に、メモしていた値を入力しましょう。
5 データベースタブも同様に、メモしていた値を入力しましょう。
※データベース・ホストは、接続するRDSの[エンドポイント]を入力します。
6 Guardiumタブには、Guardium CollectorのIPアドレスを入力します。
7 拡張機能タブは、メンバー数とワーカー・スレッド数を入力します。
メンバー数：Kubernetesノード上で動作するExternal S-TAPのPOD数となります。
ワーカー・スレッド数：ノードのvCPU数が上限のため、4 を設定します。
8 外部 S-TAP のデプロイ画面の下部の、[適用]をクリックします。
9 しばらくすると External S-TAPが表示されます。External S-TAPのデプロイができました！！
※External S-TAP → Guardium Collector の通信 が閉じていると表示されません。
忘れずにセキュリティグループ、ACLを確認しましょう。
・TCP 16016
10 Kubernetes からも確認してみましょう。
LoadBalancerが作成されています。1433/TCPポートでリッスンしていますね。
| kubectl get svc -owide |
| NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR estap1 LoadBalancer 172.20.254.41 xxxxxxxxxxxxxxxx-yyyyyyyyyyyyyyyy.elb.ap-northeast-1.amazonaws.com 1433:30961/TCP 9s app=estap1 kubernetes ClusterIP 172.20.0.1 <none> |
今度は、PODも確認してみましょう。
２つのワーカー・ノード上に、２つのPODが作成されているのがわかります。
| kubectl get pod -owide |
| NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES estap1-65f8fbc5dc-2jhk9 1/1 Running 0 43s 10.221.AA.106 ip-10-221-AA-XX.ap-northeast-1.compute.internal <none> <none> estap1-65f8fbc5dc-cmdtj 1/1 Running 0 43s 10.221.BB.201 ip-10-221-BB-YY.ap-northeast-1.compute.internal <none> <none> |
External S-TAPのデプロイはここまでです。
（３）DBクライアントからSQL実行レポートを表示
（３）- a. SQL実行
それでは、DBクライアントからAmazon RDS for SQL Serverにアクセスしてみましょう。
直接、RDSのエンドポイントに接続するのではなく、AWS ELBにアクセスすると
EKS上のExternal S-TAPに振り分けされます。
Extenal S-TAPでは、外部 S-TAP 制御画面のRDSのエンドポイントに対してアクセスします。
1 自端末にインストール済みの Microsoft SQL Server Management Studio を利用します。
サーバー名には、AWS ELBのURLを指定します。
| kubectl get svc -owide |
| NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR estap1 LoadBalancer 172.20.254.41 xxxxxxxxxxxxxxxx-yyyyyyyyyyyyyyyy.elb.ap-northeast-1.amazonaws.com 1433:30961/TCP 9s app=estap1 kubernetes ClusterIP 172.20.0.1 <none> |
2 データベースに接続できました！！
一見すると、直接RDSに接続しているように見えますが
接続先のサーバー名が変わって見えるだけで特に意識なく接続できます。
3 SQLを実行してみます。
[新しいクエリ]から、SQL Serverのオブジェクト一覧を確認するSELECT文を発行します。
4 SELECT文の結果が表示されました。
実感はありませんが、External S-TAP経由でSQLが実行されています。
（３）- b. レポート確認
SQLが実行されている裏で、External S-TAPが実行されたSQLのログをGuardium Collectorに送信しています。
実行されたSQL文をGuardium Collectorで確認してみましょう。
1 Guardium CollectorのGUI画面にログインします。
https://(Guardium CollectorのIPアドレス):8443/
2 事前に作成していたレポートを選択します。
SQL文が実行されたタイムスタンプの降順で、SQL文を表示するシンプルなレポートです。
3 実行したSQL文が表示されているのがわかります。
まとめ
いかがでしたでしょうか。External S-TAPを利用することで、クラウドのDBaaS型のデータベースログを確認することができました。クラウド環境の準備は必要ですが、External S-TAPは思ったより簡単にデプロイできるのがわかりました。今回は、Amazon RDS for SQL Server を例にしましたが、OracleやPostgreSQL、MySQLを始めとしたデータベースも同様にログ取得することができます。AWSだけではなく、Google Cloud、Azureのクラウドやオンプレでも同様です。マルチクラウドや複数種類のデータベースの構成でも、統一されたインターフェースでDB監査できるということはDB監査を考える上では大きなメリットですね。
弊社の取り扱いセキュリティソリューション
GuardiumによるDB監査によるデータ保護以外にも、ゼロトラスト時代に必要な各種セキュリティソリューションを取り扱っています。
詳しくは、弊社取り扱いのセキュリティソリューションをご参照ください。
