序文

ソフトウェア開発の重要な部分として、構成管理はコードと環境を接続する責任を負い、開発者と保守者の懸念を十分に分離することができます。

Nacosの構成管理機能は、クラウドネイティブアプリケーションの構成管理要件を満たします。構成とコードの分離の両方、および構成の動的な変更を実現できます。

1月、Nacosにはセキュリティの脆弱性があり、外部ユーザーがNacosサーバーになりすまして構成を取得/変更できるようになりました（https://github.com/alibaba/nacos/issues/4593）。問題を確認した後、Nacosは脆弱性を迅速に修正し、Alibaba Cloudのマイクロサービスエンジン（MSE）も、1月末にMSE上のNacosインスタンスに修復ソリューションをバックポートしました。

この記事では、グローバルな観点から始めて、Nacos構成のセキュリティを確保する方法、つまり、悪意のあるユーザーが構成情報を取得または漏洩しないようにする方法について説明します。

Nacos構成アーキテクチャ

Nacos構成セクションの全体的な構造は次のとおりです。

上の図のリンクごとに、認証（識別）と認証（認証）の2つの基本的なセキュリティアクションがあるかどうかを検討する必要があります。

上の図からわかるように、構成情報をリークする可能性のある方法は次のとおりです。

Nacos-clientを介して構成を取得します。
コンソールから構成を取得します。
構成は、サーバー間の通信プロトコルを介して取得されます。
構成のための永続層（DBなど）への直接アクセス。

考えられるリークポイントは次のとおりです。

	認証	認証
Nacosクライアント	ログに記録されていないユーザーは、クライアントを介して構成を取得/変更します	ユーザーがクライアントを介して不正な構成を取得/変更した
コンソールを構成する	ログに記録されていないユーザーは、コンソールから構成を取得/変更します	ユーザーがコンソールから不正な構成を取得/変更した
Nacosクラスター内	ユーザーは、構成を取得/変更するためにNacosクラスターのふりをします	必要ありません
永続層	ユーザーはDBを直接確認し、構成を取得/変更します	必要ありません

Nacosクライアントシナリオの認証と認証

Nacosクライアントがサーバーから構成を取得しようとすると、サーバーはクライアントのIDを確認し、IDに構成を取得する権限があることを確認する必要があります。

Nacosのオープンソースバージョン

デフォルトのNacosサーバー構成では、クライアントは認証されません。つまり、Nacosサーバーにアクセスできるユーザーは、Nacosに保存されている構成を直接取得できます。たとえば、ハッカーが会社のイントラネットに侵入した場合、ハッカーはすべてのビジネス構成を取得できますが、これにはセキュリティ上のリスクが確実にあります。

したがって、最初にNacosサーバーの認証をオンにする必要があります。Nacosサーバーでapplication.propertiesのnacos.core.auth.enabled値をtrueに変更します。

nacos.core.auth.enabled=true

上記の設定の後、Nacosクライアントが構成を取得するときに、対応するユーザー名とパスワードを設定して構成を取得する必要があります。

String serverAddr = "{serverAddr}";Properties properties = new Properties();properties.put("serverAddr", serverAddr);properties.put("username","nacos-readonly");properties.put("password","nacos");ConfigService configService = NacosFactory.createConfigService(properties);

上記では、ユーザーを認証する方法、つまり、現在アクセスしているユーザーを判別する方法について説明しましたが、ユーザーの権限を識別する必要もあります。インベントリの場合など、ユーザーが対応する構成を取得する権限を持っていない場合サービスが支払いサービスの構成を取得しようとすると、失敗します。

オープンソースのNacosコンソールでユーザーを作成し、権限を設定できます。次のように実行します。

まず、localhost：8848 / nacosに移動してログインし、アクセス制御-> [ユーザーリスト]ページに移動して、ユーザーを追加します。

では、アクセス制御- >ロール管理、バインドユーザーとロール：

対応するロールに権限を追加します。 権限制御->権限管理 ページで、権限を追加します。

上記の構成の後、readonly-userはパブリック名前空間の下の構成にのみアクセスできます。

Alibaba Cloud MSE-AK / SK

小規模なチームの場合、認証にはユーザー名とパスワードを使用するだけで十分です。ただし、大規模および中規模のチームの場合、定期的なパスワードの変更と頻繁な担当者の変更により、ユーザー名とパスワードが頻繁に変更されます。

現時点では、ユーザー名とパスワードの認証認証を使用するには、アプリケーションを頻繁に変更してリリースする必要があります。この問題を解決するために、NacosはAK / SKベースの認証スキームとECSがRAMロールを関連付けるスキームも提供します。これにより、ユーザー名とパスワードの変更によって引き起こされる頻繁な公開の問題を回避できます。

例としてAlibabaCloud MSEを取り上げます。AlibabaCloudユーザーは通常、許可システムとしてAlibaba Cloud Access Control Service（RAM）を使用しています。MSEがオープンソースと同じである場合、ユーザー名とパスワードが認証と認証に使用されると、ユーザーはRAMにログインする必要があり、MSENacosは2か所で権限を設定します。これは、ユーザー権限の統一された管理とレビューに不便であるだけでなく、ユーザーに一貫性のないエクスペリエンスをもたらします。

そのため、MSE（Micro Service Engine）は、AK / SKに基づく認証方式を提供します。操作例は次のとおりです。

まず、Nacos MSEアプリケーションの例（およびインスタンスIDをメモ）で、例の[詳細]-> [設定] インターフェイスで、ConfigAuthEnabled（認証の構成）パラメーターがtrueに設定されているため、匿名ユーザーは構成を取得できません。

次に、Alibaba CloudRAMシステムで関連する権限を設定できます。RAMサブアカウントの許可システムは、次のように簡単に表すことができます。

手順1：次のようにRAM権限ポリシーを作成します。

この図では、mse：Get *、mse：List *、mse：Query *は構成を読み取ることができることを示し、mse：*は変更権限を含むすべての権限を示します。

acs：mse：*：*：instance / $ {instanceId}はインスタンスレベルへの承認を意味し、acs：mse：*：*：instance / $ {instanceId} / $ {namespaceId}は名前空間レベルへの承認を意味します。

手順2：ユーザーを作成し、権限を付与します。

ユーザー名を入力します。

次に、ユーザーのAK / SKを取得します。

このユーザーに対応する権限を付与します。

最後に、コードにAK / SKを追加するだけです。

String serverAddr = "{serverAddr}";Properties properties = new Properties();properties.put("serverAddr", serverAddr);properties.put(PropertyKeyConst.ACCESS_KEY, "${accessKey}");properties.put(PropertyKeyConst.SECRET_KEY, "${secret}");ConfigService configService = NacosFactory.createConfigService(properties);

上記の設定後、クライアントがMSEで購入したNacosインスタンスにアクセスすると、MSEはAKと署名を確認し、ユーザーが正当なユーザーであることを確認し、権限を確認します。それ以外の場合、MSEはサービスの提供を拒否します。

Alibaba Cloud MSE-ECSに基づくRamロール認証

もちろん、上記の使用方法では、初期構成でAK / SKを構成する必要があります（srping-cloud-alibaba-nacos-configのbootstrap.ymlファイルなど）。ハッカーがイントラネットに侵入したり、ソースコードを漏えいしたりすると、AK / SKの漏えいも発生し、構成情報の漏えいのリスクにつながります。

この場合、認証にはECSに関連付けられたRAMの役割を使用することをお勧めします。

ECS関連のRAMロールに対応する許可モデルは次のとおりです。

上記の重要なステップはロールプレイングです。RAMロールに関連付けられているクラウドサーバーのみが、ロールを正常に実行し、MSENacosインスタンスを操作するためのアクセス許可を取得できます。

ハッカーがコードを取得するだけの場合、ハッカーはRAMの役割を果たすことができず、MSENacosインスタンスを操作できません。マシンが危険にさらされた場合、Alibaba Cloudコンソールでクラウドサーバーに関連付けられた役割をキャンセルして、時間の損失を防ぐこともできます。

具体的な手順は次のとおりです。

最初のステップは、MSE Nacosのインスタンスを作成し、対応するアクセス許可ポリシーを作成することです（上記で説明したので、ここでは繰り返しません）。
2番目のステップは、RAMロールを作成し、それを承認することです。

RAMの役割を作成します。

ロールを作成した後、ロールに対応するアクセス許可ポリシーを追加します。

3番目のステップは、役割をECSに関連付けることです。

対応するECSの詳細ページで、RAMロールの付与/撤回をクリックします。

対応する役割を選択して付与します。

コードで指定されたRAMロール の最後のステップは、次のことができます。

String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.RAM_ROLE_NAME, "StoreServiceRole");
ConfigService configService = NacosFactory.createConfigService(properties);

上記の構成後、Nacosクライアントが構成を取得すると、クラウドサーバーが指定されたRAMの役割を果たし、Alibaba Cloudの一時的なセキュリティトークン（Security Token Service、STS）がMSENacosインスタンスにアクセスします。

攻撃者がコードを取得した場合、攻撃者のマシンにはRAMの役割を果たす権限がないため、他のマシンで実行することはできません。

なりすまし後に攻撃者が認証情報を取得した場合、STSの短時間の障害（デフォルトは1時間）が原因で、攻撃者は認証情報を取得した直後に失敗し、攻撃対象領域を効果的に減らします。

承認を取り消す必要がある場合は、Alibaba Cloudコンソールで行うだけで、アプリケーションを再公開する必要はありません。

AK / SK認証および認証と比較して、ECS関連の役割の認証および認証は、より制御可能で安全であるため、この認証および認証方法をお勧めします。

コンソールシナリオでの認証と認証の構成

Nacosのオープンソースバージョン

Nacosコンソールのオープンソースバージョンでは、ログインすると、コンソールのログインインターフェイスを介して一時的なaccessTokenを取得し、その後の操作では認証にaccessTokenを使用します。

たとえば、上記のreadonly-userユーザーは、ログイン後、パブリック名前空間の下の構成情報のみを表示でき、他の名前空間の下の構成情報を変更または表示することはできません。

また、ネームスペースを作成または削除する必要がある場合は、管理者としてのみログインできます。

Nacosのオープンソースバージョンの認証と承認については、次のドキュメントを参照してください：https：//nacos.io/zh-cn/docs/auth.html。

Alibaba Cloud MSE

Alibaba Cloud MSEは企業にサービスを提供するため、権限の分割がさらに洗練されます。

リソースは、インスタンスレベル（acs：mse：*：*：instance / $ {instanceId}）と名前空間レベル（acs：mse：*：*：instance / $ {instanceId} / $ {namespaceId}）に分けられます。

リソースの操作も、次のようにさらに洗練されています。

アクション	説明
CreateEngineNamespace	名前空間を作成する
DeleteEngineNamespace	名前空間を削除する
`mse:Get,mse:List,mse:Query*`	構成の読み取り（Nacosクライアントとコンソール）
`mse:*`	構成の変更と削除を含むすべての権限
`mse:QueryNacosConfig`	クライアント読み取り構成
`mse:UpdateNacosConfig`	クライアントが構成を変更する

たとえば、1つの名前空間の下の構成のみを読み取ることが許可され、変更は許可されません。許可ポリシーは次のように記述できます。

{  "Action": [    "mse:Get*",    "mse:List*",    "mse:Query*"  ],  "Resource": [    "acs:mse:*:*:instance/${instanceId}/${namespaceId}"  ],  "Effect": "Allow"}

サーバー間の認証

一部の情報はNacosサーバー間で同期する必要があります。このとき、相手のIDを認証して、相手が偽装ではなく実際にNacosサーバーであることを確認する必要があります。

1.4.1より前は、認証はUser-Agentヘッダーを介して行われていました。この元の認証方法は、簡単に偽造できます。この記事の冒頭で述べたように、これがNacosが1月に壊した脆弱性の理由です。

したがって、バージョン1.4.1以降では、認証済みヘッダーと対応する値を自分で構成できます。application.propertiesで、次の値を変更します。

# 不使用User-Agent来认证nacos.core.auth.enable.userAgentAuthWhite=false# 认证header的keynacos.core.auth.server.identity=Authorization# 认证header的valuenacos.core.auth.server.identity.value=secret

このように、ヘッダーAuthorization: secret要求が送信された後でのみ、相手がサーバーであり、クラスター情報を同期できることを確認できます。それ以外の場合、同期は拒否されます。

Nacosサーバーは構成データを同期するためにすべての権限を必要とするため、Nacosサーバー間の認証は必要ありません。

このようにして、サーバー間の通信も安全で信頼できるものになります。

Alibaba Cloud MSEで購入したNacosインスタンスも、上記のソリューションをバージョン1.2にバックポートしており、対応するセキュリティの問題は発生しません。

永続層のセキュリティ

Nacosの構成情報は永続層に保存されます。たとえば、Nacosのデフォルトの永続層はMySQLです。

MySQLのユーザー名とパスワードがgitやその他の方法で漏洩するのを防ぐために、MySQLのユーザー名とパスワードを定期的に変更する必要があります。

通常は、UserAとUserBなどの2つのデータベースユーザーを使用します。パスワードを更新する場合は、次の手順に従います。

Nacosサーバーのユーザーを切り替えて、データベースにアクセスするユーザーAからユーザーBに切り替えます。
UserAのパスワードを更新します。
Nacosサーバーのユーザーを切り替えて、データベースにアクセスするためにUserBからUserAに戻します。
UserBのパスワードを更新します。

MSEには、Alibaba Cloud製品として、データベースのユーザー名とパスワードを定期的に変更するポリシーがあるため、MSEインスタンスを購入した場合は、この問題について心配する必要はありません。

構成セキュリティのベストプラクティス

Nacos構成セキュリティの要点を見ていくと、どうすれば構成セキュリティを確保できますか？次のベストプラクティスのみを実行する必要があります。

1.パスワードとak / skを定期的に変更します

Nacosのユーザー名とパスワード（またはAK / SK）認証を使用する場合（オープンソースのNacos認証方法を使用する場合など）、悪意のあるユーザーがNacosのユーザー名とパスワード（またはAK / SK）を取得すると、アプリケーション構成。ただし、パスワードまたはAK / SKを定期的に変更すると、構成の漏えいの期間を効果的に制限でき、攻撃対象領域を減らすことができます。

2. ECSロールを使用する（推奨される使用法）

もちろん、上記のソリューションでは、構成にNacosのユーザー名とパスワードまたはAK / SKが含まれている可能性があり、この情報もリークされる可能性があり、リーク後の変更を再公開する必要があります。したがって、Alibaba CloudのECSロールを使用することをお勧めします。すべての権限管理は、AlibabaCloudコンソールで実行されます。

3.Nacos内部認証のキーをローテーションします

前述のように、Nacosサーバー間の認証はnacos.core.auth.server.identityを介して行われますが、悪意のあるユーザーが侵入すると、リークが発生し、構成のリークが発生します。

したがって、自己構築型Nacosの場合、悪意のあるユーザーが構成を取得および変更するためにNacosサーバーになりすますことができないように、nacos.core.auth.server.identity.valueを定期的に置き換える必要があります。

もちろん、MSEによってホストされているNacosインスタンスを使用している場合、MSEは自動的にローテーションするため、これについて心配する必要はありません。

4.ローテーション永続層のユーザー名とパスワード

設定が永続層から漏れるのを防ぐために、永続層の認証情報を定期的に変更する必要があります。通常、Nacosの永続層はDBであるため、データベースのユーザー名とパスワードは定期的に変更する必要があります。

MSEユーザーの場合、何もする必要はありません。MSEは、データベースのユーザー名とパスワードを定期的に変更します。

5.安全計画を設計し、定期的に実行します

上記の重い保険では、理論的には絶対確実ですが、人間の操作には常に間違いがあるため、安全計画を指定する必要があります。

設定されたリスニングリストを定期的にチェックして、許可されていないマシンがないことを確認します。
AK / SKがリークした場合、AK / SKを更新する方法とリークしたAK / SKを取り消す方法。
自作のNacosの場合、サーバーが侵害された後にnacos.core.auth.server.identity.valueのスキームを変更する方法。

総括する

オープンソースのNacosは、基本的に、構成管理と権限管理の観点から中小企業のニーズを満たすことができます。

中規模および大規模企業の場合、Alibaba Cloud製品MSEは、より洗練された柔軟なアクセス許可構成とセキュリティ管理をサポートし、他のAlibabaCloud製品と併用してより安全な構成機能を実現することもできます。

もちろん、Nacosを自分で構築する場合でも、Alibaba Cloud MSEを使用する場合でも、構成情報の漏洩やビジネス上の損失を防ぐために、上記のセキュリティポイントに注意を払う必要があります。最後に記載されている構成セキュリティのベストプラクティスは、構成のリーク後、問題が発生する前に問題を防ぐために時間内に修復できるようにすることもできます。

募集

Dubbo / SpringCloudの商品化チームは人材を採用しています。EDASに加えて、ARMS（リアルタイムアプリケーション監視サービス）、MSE（マイクロサービスエンジン）、SAE（サーバーレスアプリケーションエンジン）などの独立した製品もあります。私たちは何をしているのですか？これらの製品を磨くことは私たちの仕事です。チームの目標は、サービスガバナンスにおけるAlibabaのベストプラクティスをAlibaba Cloudのエンタープライズ顧客に製品化の形でエクスポートし、顧客がビジネスが常にオンラインであることを認識できるようにすることです。

配信方法を再開します：https：//job.alibaba.com/zhaopin/position_detail.htm？positionId = 98290

﹀

トランザクションメッセージを通じてスナップアップビジネスの分散された一貫性を確保するにはどうすればよいですか？

2021-02-27