Public Endpoint を設定する

database は、Public Endpoint を有効にするまで VPC の内側からしか到達できません。有効にしたあと誰が使えるかを決めるのは、cluster のネットワークにある Security Group と、このタブの IP Allowlist の 2 つです。

警告

public endpoint は、利用中かどうかにかかわらずインターネット上のどこからでも到達できます。有効化するとサービスも再起動するため、ピーク時間を避けて計画し、アプリケーションが自動で再接続できることを確認してください。

前提条件

• Running 状態の cluster。最初の database を作成する を参照してください。
• アクセスさせる client それぞれの公開 IPv4 アドレス。入力欄が受け付けるのは単一アドレスで、CIDR 範囲は使えません。
• 再起動を許容できる時間帯。有効化すると既存の接続が一旦切れます。
• それぞれのアドレスからの MongoDB ポートを許可する Security Group。Floating IP で接続する を参照してください。

アクセスはどう制御されるか

public endpoint の手前には 2 つの層があり、役割が異なります。

• Security Group — cluster 側のネットワークルール。Security Group がそのアドレスからの MongoDB ポートを許可していなければ、client は public endpoint に到達すらできません。
• IP Allowlist — このタブの一覧。Security Group が通した範囲をさらに絞り込みます。

危険

Security Group がすべてのアドレスを許可していると、IP Allowlist は何も制限しなくなり、database はインターネットに開かれた状態になります。allowlist に入れたアドレスと一致するよう Security Group を設定し、変更するときは必ず両方を揃えてください。

public endpoint を有効にする

database を開き、Public Endpoint タブを選びます。3 つのアーキテクチャすべてで利用できます。有効化前のタブには、ステータスと Enable ボタンしかありません。

1. Enable をクリックします。

2. 2 つの注意書きを確認します。endpoint がインターネットから到達可能になり、この操作ではサービスが再起動するため、実行中は接続が切断されます。

3. 最初の access rule を入力します。IPv4 address は必須、Description は任意ですが埋めておく価値があります。数か月後に一覧を見直すとき、その rule が存在する理由を示す唯一の手がかりになるからです。

   

4. 同じ手順で複数のアドレスを宣言するには Add access rule を使い、最後に Enable をクリックします。

ステータスは進捗バー付きの Processing に変わり、再起動中は database 自体も Updating になります。数分かかります。完了すると Active になり、公開用の接続文字列とそれを守る allowlist がタブに表示されます。

rule を 1 件も指定せずに有効化することはできません。アドレス欄に妥当な IPv4 が入るまで、Enable ボタンは無効のままです。

public endpoint 経由で接続する

1. タブの Public connection string をコピーします。
2. database の Overview タブから username と password を読み取ります。database cluster の情報を見る を参照してください。
3. mongosh、Compass、またはドライバで接続します。private な文字列を使っていた場所に、公開用の文字列を入れます。

mongosh "mongodb://<USERNAME>:<PASSWORD>@<HOST>:27017/admin?replicaSet=<CLUSTER_ID>"

文字列にはホスト、ポート、database 名がすでに含まれているため、足すのは認証情報だけです。何が並ぶかは database の構成によって変わります。

アーキテクチャ	公開用文字列に並ぶもの
Standalone	単一 node。replicaSet パラメータは残ります
ReplicaSet	データを保持するすべての node と replicaSet パラメータ
Sharded Cluster	mongos router のみ。replicaSet パラメータはありません

ヒント

認証エラーではなく、接続が応答せずタイムアウトする場合は、認証ではなくネットワークで遮断されています。まず Security Group を確認し、次に client の現在の公開 IPv4 を allowlist と照合してください。オフィスや自宅のアドレスは予告なく変わることがあります。

access rule を追加する

1. allowlist テーブルの上にある Add access rule をクリックします。
2. IPv4 address を入力し、必要なら Description も入れます。
3. ダイアログ内の Add access rule で複数のアドレスをまとめて宣言し、Add をクリックします。

この欄が受け付けるのは単一の IPv4 アドレスです。CIDR 範囲は IPv4 address fails to match the pattern として拒否されます。

重複するアドレスは送信前、入力している最中に検出されます。

rule の追加は即時ではありません。処理はバックグラウンドで走り、完了してから allowlist に行が現れます。数分かかります。進行状況はタブ下部の Action logs で確認できます。

access rule を削除する

1. allowlist テーブルの上にある Delete rule をクリックします。
2. 削除する rule にチェックを入れます。それらに依存している client がアクセスを失う旨の警告が表示されます。
3. Delete をクリックします。

有効な endpoint には最低 1 件の rule が必要で、console は 2 か所でそれを強制します。残りが 1 件のときは Delete rule ボタン自体が無効になります。複数ある場合もダイアログは開きますが、すべてを選択している間は Delete ボタンが無効のままで、チェックを 1 つ外すと有効に戻ります。

最後のアドレスを消すと、公開されているのに誰も到達できない endpoint が残ります。そのための制約です。アクセスを完全に閉じたい場合は、endpoint を無効化してください。

public endpoint を無効にする

1. タブ右上の Disable をクリックします。

2. 確認欄に disable と入力します。

   

3. Disable をクリックします。

public endpoint を使っている client は直ちに接続を失います。private VPC endpoint 経由の接続は影響を受けないため、VPC 内のアプリケーションはそのまま動作します。ステータスは Inactive に戻り、公開用の接続文字列は消え、allowlist も一緒に失われるため、あとで再度有効化するときはアドレスを宣言し直すことになります。

公開範囲を最小限に保つ

IP Allowlist は誰かを認証するものではなく、Security Group がすでに開けたものを取り消すこともできません。本当の防御線は Security Group だと考え、インターネットに面したサービスと同じ強度の認証情報を database に設定してください。

• Security Group と IP Allowlist を同じアドレス集合に保ちます。一方から外され、もう一方に残ったアドレスが、見つけ出される隙間になります。
• すべての rule に、どの client のものかを示す Description を付けます。裸のアドレスが並ぶだけの一覧は、見直す人に何も伝えません。
• その rule の client がアクセスを必要としなくなったら、すぐ削除します。放置された行は、誰も見ていない扉です。
• endpoint を必要とした作業が終わったら無効化します。次に使うまで有効のままにしないでください。
• 本番のトラフィックは private VPC endpoint に残します。public endpoint が向いているのは、外部連携、一時的な管理アクセス、開発やテストです。

次のステップ

• Floating IP で接続する。private と public のアクセスモデルを比べてから選べます
• action log を見る。実行中の有効化、追加、削除の進行状況を追えます
• database cluster の情報を見る。public endpoint と並んで存在する private endpoint を確認できます