はじめに

前回の記事で、Amazon RDS(MySQL)の監査ログについて、フォーマットを確認しました。
Amazon RDS(MySQL)の監査ログのフォーマットを確認する【MARIADB_AUDIT_PLUGIN】

ログの読み取り方が分かったところで、実際に出力されたログを見た時にあれ？と思ったことがあるので、それについて記します。

20190707 20:30:55,ip-172-23-2-48,root,10.100.xx.xx,1234567,0,DISCONNECT,,,0 

20190808 10:15:30,ip-10-7-1-52,testdbuser,172.16.xx.xx,2345678,23456789,QUERY,testdb02,'SET autocommit=1',0

20190909 05:25:25,ip-10-7-1-52,rdsadmin,localhost,3456789,98765432,QUERY,,'SELECT 1',0

ちなみに

本記事内においては「RDSインスタンス」と表記していますが、恐らく「DBインスタンス」が正しい名称です。

前提の構成

例1と例2,3で、環境は異なるのですが、いずれも以下の構成となっています。

• 同一のVPCにEC2とRDSがある
• EC2とRDSは異なるサブネットに所属している
• EC2からSqlクライアントでRDSに接続している

イメージでは以下となります。

この構成におけるRDSから出力されたログを、例として取り上げています。

監査ログを読んでみる

ログのフォーマットは以下の通りです。

[timestamp],[serverhost],[username],[host],[connectionid],[queryid],[operation],[database],[object],[retcode]

各フィールドの説明と、今回の構成に当てはめたときの別名を以下にまとめます。
（気を抜くと、「usernameって接続元EC2で使用しているOSユーザ名だっけ？」「hostってRDSとEC2どっちだっけ？」となる人間なので、勝手な呼称をつけています。）

冒頭で記載したログの例1-3を当てはめると以下のようになります。

以下、読んで気になったところを記します。

1.RDSインスタンスの「本体」があるであろうIPレンジ

なんか見慣れないIPアドレスあんだけど…。と思った話です。
ほぼこの記事で言いたいことのすべてです。

DBをホストするサーバのIPアドレス

上記の表における#2の「接続先RDSインスタンス」は、言い換えれば、「DBから見て、自身をホストしているサーバのホスト名」です。そして、ip-xx-xx-xx-xxというホスト名の命名規則は、そのサーバにxx.xx.xx.xxのIPアドレス（例1であれば172.23.2.48）が採番されていることを表すと考えられます。それは、EC2のデフォルトのホスト名が、そのような命名規則に則っている（ことが多い）ためです。

[Linux インスタンスのホスト名の変更]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/set-hostname.html

インスタンスを起動すると、プライベートの内部 IPv4 アドレスの形式のホスト名が割り当てられます。典型的な Amazon EC2 プライベート DNS 名は、ip-12-34-56-78.us-west-2.compute.internal のような形式になります。この名前は内部ドメイン、サービス (この例では、compute)、リージョン、そしてプライベート IPv4 アドレスで構成されます。インスタンスにログインしたとき、このホスト名の一部がシェルプロンプトで表示されます (ip-12-34-56-78 など)。

その想定が正しい前提で、以下を続けます。

接続元EC2インスタンスが所属するIPレンジとの違い

ログの例1と例2について、IPアドレスに関する部分のみ抜きだします。

いずれも、接続先であるRDSインスタンスと、接続元であるEC2インスタンスのIPアドレス範囲が、異なるクラスに所属しているものであることが分かります。

（クラスAやらクラスBやらについては以下を参照のこと）

[RFC 1918 – Address Allocation for Private Internets]
http://www.faqs.org/rfcs/rfc1918.html

3. Private Address Space

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private internets:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

   We will refer to the first block as "24-bit block", the second as
   "20-bit block", and to the third as "16-bit" block. Note that (in
   pre-CIDR notation) the first block is nothing but a single class A
   network number, while the second block is a set of 16 contiguous
   class B network numbers, and third block is a set of 256 contiguous
   class C network numbers.

サンプル数が2つだけなのでなんとも言えないですが、今回の構成で言えば、必ず異なるクラスのIP範囲が割り当てられるのだろうと思います。

他のアプローチから確認するRDSインスタンスのIPアドレス

前提構成をおさらいすると、EC2インスタンスとRDSインスタンスは同じVPCに所属しています。VPCに対してはCIDRの追加を行っていません。³

RDSインスタンスに接続する際にはエンドポイント（例：mysql–instance1.123456789012.us-east-1.rds.amazonaws.com）を指定して接続することになりますが、今回の構成においてエンドポイントを名前解決すると、EC2インスタンスと同一のクラスのIPが返却されます。

また、RDSインスタンスと同時に作成されるENIをマネジメントコンソールから確認しても、同様にEC2インスタンスと同一のクラスのIPアドレスが確認できます。

AWSマネージドVPC（仮称）に存在している土台

• 監査ログ上でのRDSインスタンスはEC2インスタンスとは異なるクラスのIPを持つ
• 素直にRDSインスタンスに接続を試みる場合、接続先IPはEC2インスタンスと同一のクラスのIPである

上記もろもろを鑑みると、下記のような構成が妄想できます。

• DBをホストするサーバ自体は、ユーザ（AWSカスタマー）の管理対象外のVPCに存在している
• 上記のサーバは2つ以上のネットワークインタフェースを持っており、その一つがユーザが管理するVPCに足を延ばしている
• AWSユーザから見えるRDSインスタンスのIPアドレスは、上記のネットワークインタフェースのものである

RDSにおいては、DB層より下（OS、仮想マシン、物理ホスト、物理ネットワーク…）は基本的にAWSが面倒を見てくれており、まさにその面倒を見ている場所がAWSマネージドVPC（仮称）なのかなと想像します。

面倒を見てくれる一覧。

20180425 AWS Black Belt Online Seminar Amazon Relational Database Service (Amazon RDS)より
https://www.slideshare.net/AmazonWebServicesJapan/20180425-aws-black-belt-online-seminar-amazon-relational-database-service-amazon-rds-96509889/11

ユーザの管理対象外のVPCの存在

上記の構成は名称も含めてすべて個人の妄想ですが、ユーザ管理対象外のVPCの存在は、公式の情報として確認できます。

Amazon WorkSpaces

[Amazon WorkSpaces とは – アーキテクチャ]
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/amazon-workspaces.html#architecture

上記ページより画像を引用。

AWS-Managed VPCとCustomer-Managed VPCが区別して表現されています。
WorkSpacesのインスタンスを立てた時、ユーザから見えるENIはCustomer-Managed VPCに属するものだけです。

（このあたりを頑張って調べたときの記事はこちら。）
[画像つき]WorkSpacesをひとまずQuick Setupで構築してアーキテクチャをざっくり理解する【アーキテクチャ編】

VPC内Lambda

[[発表] Lambda 関数が VPC 環境で改善されます]
https://aws.amazon.com/jp/blogs/news/announcing-improved-vpc-networking-for-aws-lambda-functions/

同じく画像を引用。

AWS Lambda Service VPCとCustomer owned VPCが区別されています。
WorkSpacesの場合と名称は異なりますが、ユーザの管理外のVPCがあることが読み取れます。

2.作成した覚えのないDBユーザrdsadmin

言いたいことはほぼ言い終わったので、以下はほぼおまけのようなものです。
改めてログの出力例から一部をピックアップします。

#3のusernameについて、例1のrootと例2のtestdbuserは自前で作成した覚えがあるのですが（前者はRDSインスタンス作成時のマスタユーザとして、後者はCREATE USERで）、例3のrdsadminというユーザは作成した記憶がありません。

これについては、自動作成される旨、ドキュメントに記述がありました。

[Amazon RDS での MySQL のセキュリティ]
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.UsersAndPrivileges

各 DB インスタンスに管理サービスを提供するために、DB インスタンスの作成時に rdsadmin ユーザーが作成されます。rdsadmin アカウントの権限をドロップ、名前変更、パスワード変更、または変更しようとするとエラーになります。

ざっと見た感じ、DBエンジンの種類に関わらず作成されるようです。接続元ホストはlocalhostが記録されていますが、これもRDSインスタンスの「本体」のほうを表しているのだろうなと思います。

3.その他

これはただ単に知らなかっただけなのですが、コネクションIDについての仕様です。

• CONNECTされた後にQUERYが実行される（そもそもの前提）
• QUERYがどのコネクションで実行されたかを、ログから追うことができる
• CONNECTの対になるDISCONNECTが記録される（両者はコネクションIDが同一である）

DBに疎いと、こういうことも新鮮に感じられます。

おわりに

どこか別の場所で管理されているというのは暗黙的にわかっていたことではありましたが、監査ログという目に見える形でその存在が思い起こされたので、ちょっと得した気分になりました。

ELBなんかもきっと同じように「本体」は別のVPCで管理されているのだろうなと思います。