DB & Server Access Control とは

最新のコンテンツが反映されていません。早急にアップデート内容をご提供できるよう努めております。最新のコンテンツ内容は韓国語ページをご参照ください。

VPC環境で利用できます。

DB & Server Access Controlサービスを理解して簡単に活用できるよう、導入の必要性、サービス構造、動作方法、主要な用語について説明します。

DB & Server Access Controlの必要性

現代のクラウド環境では、データベースとサーバへのアクセス制御が、企業のセキュリティレベルを左右します。特に、個人情報保護法、ISMS-P、電子金融監督規定などの様々な規制では、アクセスの権限管理とアクセス履歴の保管が必須条件として求められています。DB & Server Access Controlサービスは、すべてのアクセスを Proxy経由で中央制御することで、最小権限の原則を技術的に実現します。また、ユーザー別のセッション記録とタスク履歴を保存し、監査および規制対応に必要な証跡を提供します。これにより、内部者による脅威、権限の誤用・不正利用、協力会社のアカウント管理不足により発生し得るセキュリティリスクを未然に防止できます。結果として、DB & Server Access Controlサービスは単なるセキュリティ機能ではなく、組織の内部統制システムと規制遵守をサポートする必須インフラです。

• 規制遵守: 公共、金融、医療などの規制産業を含む大企業独自のセキュリティ基準を満たす中央集中型アクセス制御システム
• 内部統制: 内部者によるセキュリティ事故の防止と、退職者・協力会社のアクセス権限管理
• 監査対応: ユーザー、リソース別のアクセス履歴とタスク実行履歴に関する証跡管理と追跡確保

サービスの構造

DB & Server Access Controlサービスは、ユーザーがサーバやデータベースへ直接アクセスする代わりに、プロキシサーバを必ず経由するようアクセスパスを一元化します。単一の経由ポイントでアクセス権限を制御し、専用 Clientを通じてアクセスしたユーザーの実行履歴をロギングして監査機能を提供します。

上記の概念図は、DB & Server Access Controlサービスの利用フローを、管理者(Admin)とユーザー(User)の観点から示します。管理者(Admin)は、NAVERクラウドプラットフォームコンソールでプロキシサーバとアクセス制御ターゲットを設定します。ユーザー(User)は、専用 Clientをセットアップし、認証後にプロキシサーバを経由して対象リソースにアクセスします。この過程で発生するすべてのアクセス・タスク履歴がロギングされます。この流れを構成する主な要素は、次の通りです。

• NAVERクラウドプラットフォームコンソール: 管理者がプロキシサーバの配信、アクセス制御ターゲットの登録、アクセス権限・ロギング・マスキングを設定する管理画面
• 専用 Client: ユーザー PC(Windows、macOS)にインストールするエージェントソフトウェアで、Sub Account(サブアカウント)でログインし、ユーザーのすべてのアクセストラフィックをプロキシサーバへ転送するエントリポイントの役割。Clientを経由しないアクセスは遮断されるため、アクセス制御を適用するための必須要素
• プロキシサーバ: クライアント VPCの Private Subnetに自動的に配信されるゲートウェイサーバ。ユーザーと対象リソース間の接続を中継し、アクセス権限を確認するとともに、実行されたコマンドと結果値をロギング。この際、NAVERクラウドプラットフォームが直接管理する管理網と連携し、アクセスポリシーを定期的に取得する役割を担う
• 対象リソース(アクセス制御の対象): アクセス制御とロギングの対象となる個人情報処理システムで、Cloud DB(MySQL、MSSQL、PostgreSQL、MongoDB、Redis)、Server(Linux)、Serverに直接インストールした DBMSが対象
• 連携サービス: アクセスおよびタスク履歴ログは Cloud Log Analyticsに転送されて保存・照会され、コンソールで実行した設定履歴は Cloud Activity Tracerに記録。ログの長期保存のため、Object Storageの利用を推奨

動作方法

DB & Server Access Controlサービスの動作方法について、重要な原理とステップごとの流れに沿って説明します。これを理解することで、コンソール上で推奨シナリオに沿ったサービス構成および活用を行う際に役立ちます。

重要な原理

重要な原理は次の通りです。

• すべてのアクセスはプロキシサーバを単一経由
  ユーザーが対象リソースへ直接アクセスできれば、アクセス制御とロギングの有効性が失われます。そのため、対象リソースの Access Control Group(ACG)および Network ACLにおけるユーザーの直接アクセスルールを削除し、プロキシサーバへのアクセス許可ルールのみを追加する必要があります。これにより、すべてのアクセスが統制・記録される構造が完成します。ACG設定に漏れがあると、ユーザーがプロキシを迂回できるため、これはサービス利用時の前提条件となります。
• アクセス権限は Sub Accountポリシーで管理
  別途の権限システムを用意することなく、Sub Accountのユーザー定義ポリシーを活用します。管理者がアクセス制御ターゲットに対する権限をポリシーとして定義してサブアカウントに関連付けると、プロキシサーバがログイン時にポリシーを確認してアクセスの許可・拒否を判断します。
• 実行履歴はプロキシサーバから収集
  対象リソースの設定を変更することなく、プロキシサーバが中継する過程でユーザーが実行したコマンド、クエリおよび結果値を収集し、Cloud Log Analyticsサービスへ転送します。この際、結果値に含まれる可能性のある個人情報は、転送前にマスク処理できます。

ステップごとの流れ

ステップごとの流れは次の通りです。

環境構成(管理者)

管理者が環境を構成する流れは、次の通りです。

1. DB & Server Access Controlサービスのご利用の申し込み時に、VPC、Subnet、サーバ仕様を選択してプロキシサーバを作成
2. 対象リソースの ACG/Network ACLにおけるユーザーの直接アクセスは遮断し、プロキシサーバへのアクセスを許可
3. アクセス制御対象を、サーバターゲットまたは DBターゲットとして登録し、ロギング範囲とマスキングを設定
4. Sub Accountのユーザー定義ポリシーで Targetのアクセス権限を定義し、サブアカウントに関連付ける

アクセスとロギング(ユーザー)

ユーザーが Clientを通じてアクセスし、ユーザーの利用履歴がロギングされる流れは、次の通りです。

1. ユーザーが PCに専用 Clientをセットアップし、サブアカウントでログイン
2. Clientがプロキシサーバからアクセス権限のあるリソースリストを取得して表示
3. ユーザーがアクセスツール(ターミナル、DBクライアントなど)でアクセスをリクエストすると、トラフィックが Clientを通じてプロキシサーバへ転送
4. プロキシサーバがアクセス権限を確認し、対象リソースへの接続を中継
5. 実行したコマンド、クエリおよび結果値がロギングされ、Cloud Log Analyticsサービスへ転送(必要に応じて個人情報のマスキングを適用)
6. 転送されたログは Cloud Log Analyticsサービスで監査および照会し、Object Storageを通じて長期保存可能