はじめに

データベースのメンテナンスをセキュアかつモダンにやるにはどうしたらいいんだろうと考えたことはありますか？
CICDが昨今叫ばれるなかAPはパイプライン化したもののDBはどうしようというケースが多いのではないでしょうか
ガバメントクラウドを例にみると、仮想マシンではなくマネージドサービスを活用するように、ならびにインターネット接続を原則とすること、手作業をできる限り排除するようにすることが求められています。
どういった構成が考えうるのかを本記事では解説していきます。

従来の構成

VPN構成

まず最初のパターンがVPNパターンです。SitetoSite、ClientVPNどちらでもよいですが、VPN経由でDBに接続、クエリを叩く構成となります。

踏み台構成

２つ目のパターンがSSM経由の踏み台サーバとなります。
踏み台経由でDB接続を行い、クエリを叩きます。

２つの構成の問題点

まず、VPNパターンでは、一度アクセスを許可すると内部ネットワークを信頼するという考えのもと、信頼された通信を原則としているがゆえセキュリティホールとなりえます。内部からの脅威や情報漏洩などが発生した場合、VPNを経由した攻撃を許容してしまうことにもなりかねず、ゼロトラストの観点からすると、適切な認証や制御を入れない限り利用に注意が必要です。
２つ目の踏み台サーバパターンでは、OSの管理が必要であるというデメリットがあります。OSの脆弱性対策、パッチ管理等々運用コストがかかります。
また、どちらの場合でも、手動でのDBメンテナンスということで、作業ミスなどのインシデントを引き起こす可能性があり定常時の利用はおすすめできません。

モダンなアーキテクチャ　その１　ガバメントクラウドのガイド

まずは、ガバメントクラウドの例を見て参考にしてみましょう。
DBメンテナンスの例が記載されています。

以下５パターンが公開されています。
パターン１、２は定常的なもの、パターン３、４，５は非定常的なものです。

メンテナンス_DB直接メンテナンス機能　（パターン1 定常作業、Lambda経由での操作）

メンテナンス機能をWEBAPにしてしまうパターンですね。
インターネット経由で認証を実施したうえで、LambdaからDBのメンテナンスを行っています。
Lambdaの実行時間制限やリソース制約に注意が必要でしょう。

メンテナンス_DB直接メンテナンス機能　（パターン2 定常作業、ECS経由での操作）

これもパターン１と同様にメンテナンス機能をWEBAPにし、コンテナ経由でDBのメンテナンスを行っています。
このパターンだと、Lambdaのリソース制約もないため、実行時間が長いなどのものは、こちらのケースが向いているでしょう。

メンテナンス_DB直接メンテナンス機能　（パターン3 非定常作業、AWSコンソール+SSMを介したEC2経由での操作）

これは実質的な踏み台構成ですね。以下注意事項が記載されている通り、緊急時のみかつ、常設しないようにという注意が記載されています。

1 緊急時・障害時のみEC2を起動して利用すること。 EC2起動テンプレートを使用することで効率性、正確性を向上させるため、項番2以下に従って起動テンプレートを作成し、EC2を起動する。
2 EC2起動時は、常に最新のAMIを使用することで、脆弱性の混入を最小限に抑えること。 EC2起動テンプレートでは最新AMIを指定できないため、起動時にクイックスタートAMIより最新のAMIを指定する。
なお、クイックスタートAMIにクライアントツールは含まれていないため、S3などに資材を事前格納し、EC2起動時のユーザデータを用いたコマンド自動実行で資材取得、インストールする。
3 IAMロールの権限は必要最小限とすべきのため、Session Managerで接続するためのIAMロールを作成して、アタッチすること。要件に合わせてIAMインスタンスプロファイルを作成する。
作成したIAMインスタンスプロファイルをEC2起動テンプレートにて指定する。
4 インターネットアクセスできないようにプライベートサブネットに配置すること。 EC2起動テンプレートにてデプロイするプライベートサブネットを指定する。
5 意図しない利用や課金、また、脆弱性への攻撃を防ぐため作業終了後はEC2を必ず終了すること。 EC2終了を行う。

メンテナンス_DB直接メンテナンス機能　（パターン4 非定常作業、AWS CLI+SSMを介したEC2経由での操作）

これもパターン３と同じですが、違いは、マネジメントコンソールではなく、CLI経由の接続のパターンです。

メンテナンス_DB直接メンテナンス機能　（パターン5 非定常作業、AWS CLI+SSM+ポートフォワーディングを介したEC2経由での操作）

これもパターン３と同じですが、違いは、マネジメントコンソールではなく、ポートフォワーディング経由の接続のパターンです。

モダンなアーキテクチャその２　他にないのか？

ガバメントクラウドの構成ではざっと以下２つの要点が記載されています。
・定常的な作業はAP化する
・非定常的なものはEC2orECS経由でのクエリを実行する。一時的な利用に限定する

どちらかというと、既存DBへのクエリ等々の視点なのかなと思いますが、DBの変更操作も含めて
他の構成がないか考えてみます。

案1 パイプライン化

Codeシリーズを使います。DBへのクエリ、変更操作をドキュメントとして格納、CodeBuildによって変更操作、テストを実施します。必要に応じて承認アクションやリカバリ操作をスクリプトとして組んでおくとよいでしょう。
これにより、DBの変更に仮想サーバを用意せずとも実施が可能です。

案2 AP組み込み

ガバメントクラウドパターン１、２と類似しますが、どちらかというと既存APコンテナ側に仕組みを作ります。
例としてFlywayを取り上げます。
Flywayは、データベースのバージョン管理とマイグレーションを自動化するツールです。SQLベースのスクリプトを適用し、データベーススキーマを管理・更新できます。特にCI/CD環境でのデータベースデプロイに適しており、多くのRDBMS（PostgreSQL、MySQL、SQL Server、Oracleなど）をサポートしています。
SpringBootにFlywayを組み込むことで、DBを管理することができます。結果的にコンテナ側に組み込むことができるため、既存のAPのCICDパイプラインでDBの変更も実施可能になるわけです。

案3 Lambda実行

Lambdaを利用するパターンです。
クエリ等々をS3に格納し、Lambdaが実行を行います。リソース制約には気をつける必要がありますが、ちょっとデータを取りたいなどの操作でも気軽に実行できるのが特徴です。

案4 Verified Access

VerifiedAccessを利用するパターンです。VerifiedAccessではVPC内の任意のリソースに対してTCP接続がサポートされています。インターネット経由で認証プロバイダでの認証を挟み、DBへ接続することが可能です。
これまでとは異なり、コマンドを人が打つことになることに注意が必要です。非定常的な運用の際に利用することを検討しましょう。また、認証プロバイダの用意が必要ですので、導入、運用コストにも注意が必要です。

案5 QuerryEditor

Auroraでは、一部リソースにおいて、QueryEditorが利用可能です。なお、QueryEditorの利用にはDataAPIが利用できる必要があり、Serverlessタイプのみが現状対応しています。
ブラウザから任意のクエリが実行可能です。

まとめ

#	ケース	想定ケース、特徴など	留意事項
1	ガバメントクラウドパターン1 定常作業、Lambda経由での操作	定常的な情報取得、メンテナンス	Lambdaの実行時間制約等リソース制約に注意、どこまでの操作を想定するか事前に決める必要がある
2	ガバメントクラウドパターン2 定常作業、ECS経由での操作）	定常的な情報取得、メンテナンス	どこまでの操作を想定するか事前に決める必要がある
3	ガバメントクラウドパターン3、4、5 非定常作業、EC2経由での操作	緊急時のDBアクセス	OSの管理が必要、手動操作のため、作業ミスに注意が必要
4	案1 パイプライン化	DBの変更を伴うデプロイ等	DBの変更がうまくいかなかった場合のロールバックなどを考える必要がある、スクリプトの設計が必要
5	案2 AP組み込み	DBの変更を伴うデプロイ等、AP側のデプロイとセットでDBへの変更がデプロイ可能、APパイプラインでバージョンが管理できる	AP側が対応しているか注意が必要
6	案3 Lambda実行	DBから情報を取りたいとき、DBの変更操作をしたいときなど	Lambdaの実行時間制約等リソース制約に注意、パイプラインと異なり、承認フェーズがないため注意
7	案4 Verified Access	緊急時アクセス	認証プロバイダのコストに注意、手動作業のため作業ミスに注意
8	案5 QuerryEditor	緊急時アクセス	一部リソースのみの対応、手動作業のため作業ミスに注意

特徴をまとめました。様々な特徴や選択肢がありますが、適切に選択していきましょう。基本的には、作業の自動化が第一であり、例外的な事情において、緊急時アクセスの手動操作という手段を確保しておく事が重要です。その手段もさまざまですので、セキュリティ、コストなどを意識してアーキテクチャを考える必要があります。