Secure Deployment Plan¶

Introduction¶

For customers in finance, insurance, and other industries with high security sensitivity, as well as those who require self-control over the data provided by "Guance", we offer a solution that deploys the product into the customer's own controllable environment. However, if we cannot provide long-term, timely, and rapid upgrades and management for these "Guance" instances deployed on the customer side, the customer may not be able to upgrade effectively and in a timely manner, or may encounter bugs that cannot be fixed. Therefore, in this Deployment Plan cooperation model, we need to help customers upgrade and maintain the entire system in a secure and controllable manner, so that these Deployment Plan customers can enjoy the same service experience as the SaaS version under absolute security.

Potential Issues¶

In fact, there are many concerns regarding our engineers deploying, installing, maintaining, and upgrading the "Guance" product on the customer's own servers. These concerns include the following:

Systemic Security Risks of "Guance"

Concerns that after deploying "Guance" in the enterprise intranet, security risks inherent in "Guance" itself, or distrust of the engineers operating "Guance", could lead to issues such as: traditional intranet attacks, using the "Guance" deployment cluster as a springboard to attack the customer's intranet environment, or operators exploiting permissions during deployment and management to launch intranet attacks.

Data Leakage Risks of "Guance"

Concerns about data leakage from the "Guance" product itself, including data being stolen or destroyed by personnel performing upgrade operations.

Due to these concerns, customers refuse to allow our engineers to install, upgrade, or maintain the software, while the customers themselves lack the necessary technical skills. When system failures occur, they cannot handle them effectively, resulting in a severely degraded user experience.

Solution¶

"Guance" itself is a comprehensive observability platform. It is a data receiver and does not need to access any monitored objects on its own. All monitored objects have their data packaged by DataKit and then pushed to the center of "Guance" in a client manner. Therefore, by properly building a secure deployment environment, the above security risks can be eliminated, and customers can fully entrust us with the maintenance, management, and updates of the product, allowing them to enjoy a SaaS-like experience without worrying about system deployment issues.

Independent Cloud Account (Recommended):¶

Open a dedicated account for deploying "Guance" on an independent cloud platform, achieving complete isolation from the customer's production or test environment. This physically (logically) ensures that when our engineers are maintaining, managing, or updating the "Guance" product, they cannot use the "Guance"-related servers as a springboard to attack the customer's business network. Due to the architectural characteristics of "Guance", it is only necessary for the objects to be observed in the customer's intranet to transmit data to the DataWay of this "Guance" via DataKit, i.e., ensuring a one-way TCP connection from DataKit to the centrally deployed DataWay.

VPC Isolation¶

Open an independent VPC under the same cloud platform account, deploy "Guance" into this independent VPC, and configure appropriate routing rules to ensure that the DataKit of the core system can access the DataWay deployed in the independent VPC one-way. At the same time, create an independent RAM account and grant all cloud resources under this independent VPC to that RAM account.

Physical Network Isolation¶

Use iptable or security groups on the physical network to restrict the cluster where "Guance" is deployed from accessing other intranet servers, and only open the DataWay port in "Guance" to the DataKit to achieve a one-way TCP connection.

Further Strengthening¶

The three methods above can already prevent attacks on the core business system from hackers who have infiltrated "Guance", or from malicious engineers while maintaining "Guance". However, to protect the "Guance" platform and the data within the "Guance" platform, we still need to apply some additional hardening configurations.

Enable Cloud Platform Operation Audit¶

Enable the audit function and record audit logs into an audit workspace of "Guance". This allows you to see all actions performed by logging into the cloud console with the RAM account, ensuring that all maintenance and management activities are auditable in the cloud console.

Enable Bastion Host¶

All SSH-based logins to the relevant clusters for managing the "Guance" cluster are audited through the bastion host.

Properly Manage RAM and Bastion Host Accounts¶

Have the customer's internal engineers manage the process: only open the corresponding RAM account and enable bastion host permissions when we need to perform system update management, and regularly update passwords or keys to avoid intrusions caused by daily system password leakage.

Conclusion¶

In summary, by adopting a reasonable deployment method, customers can confidently entrust us with the full maintenance of the Deployment Plan "Guance" without any concerns about risks—such risks will be impossible.