Adds recs sections to security pages (#37)

sarahsimpers · web-flow · commit 5e98e468872d · 2024-11-18T08:59:26.000-05:00
diff --git a/source/auditing-logging.txt b/source/auditing-logging.txt
@@ -9,18 +9,21 @@ Auditing and Logging
 .. contents:: On this page
    :local:
    :backlinks: none
-   :depth: 1
+   :depth: 2
    :class: onecol
 
 To monitor and log |service| platform activities, use auditing and logs.
 
-{+service+} Features and Best Practices for Auditing and Logging
-----------------------------------------------------------------
+{+service+} Features and Recommendations for Auditing and Logging
+-----------------------------------------------------------------
+
+Features
+~~~~~~~~
 
 .. _auditing:
 
 Auditing
-~~~~~~~~
+````````
 
 Database auditing lets you track system activity for deployments with
 multiple users. As a |service| administrator, you can:
@@ -53,7 +56,7 @@ multiple users. As a |service| administrator, you can:
 .. _accessing-audit-logs:
 
 Accessing Audit Logs
-~~~~~~~~~~~~~~~~~~~~~
+````````````````````
 
 .. include:: /includes/cloud-docs/logs.rst
 
@@ -77,9 +80,61 @@ for an organization or project.
 To perform a full audit, you can use a combination of audit logs,
 the ``mongodb.log``, and :ref:`the project activity feed <view-activity-feed>`.
 
-You can use the ``atlas deployments logs`` command in the {+atlas-cli+}
-to retrieve deployment logs. To learn more,
-see :atlas:`Atlas Deployment Logs </cli/current/command/atlas-deployments-logs/>`.
+Recommendations for Auditing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For development and testing environments, do not enable auditing. This
+saves costs in your non-production environments.
+
+For staging and production environments, enable auditing for
+additional security. We recommend that you audit the following events at a minimum:
+
+- Failed logon
+- Session activity
+- Logon and logoff
+- Attempts to perform unauthorized functions
+- Password change
+- Database User Access Changes
+- DDL & System configuration stored procedures
+- Modification of Native audit
+- Run a backup or restore
+- Alter DBMS native audit settings
+- Alter security
+- Database Start and Stop Commands
+
+For all of the previous events, you should include the following
+information at a minimum:
+
+- Session ID
+- Client hostname and IP address
+- Database server hostname and IP address
+- Database user
+- OS user
+- Database name
+- Service/instance name
+- Port
+- Application
+- Query
+- SQL command
+- Object
+- Timestamp
+- Error code (if applicable)
+
+Recommendations for Audit Logs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To integrate with tools beyond the built-in integrations, we recommend
+that you retrieve logs with the following tools and feed the JSON-formatted output to your external tools:
+
+- Use the ``atlas deployments logs`` command in the {+atlas-cli+}
+  to retrieve deployment logs. To learn more,
+  see :atlas:`Atlas Deployment Logs 
+  </cli/current/command/atlas-deployments-logs/>`.
+- Use the {+atlas-admin-api+} endpoints for :oas-atlas-tag:`Logs <MongoDB-Cloud-Users>` and :oas-atlas-tag:`Project Events <Events>` to
+  retrieve deployment logs and lists of project events.
+- If you use |aws|, you can continually push logs to an |aws| S3
+  bucket. To learn more, see the
+  :oas-atlas-tag:`Push-Based Log Export <Push-Based-Log-Export>` {+atlas-admin-api+} endpoints.
 
 Examples
 --------
diff --git a/source/data-encryption.txt b/source/data-encryption.txt
@@ -9,44 +9,59 @@ Data Encryption
 .. contents:: On this page
    :local:
    :backlinks: none
-   :depth: 1
+   :depth: 2
    :class: onecol
 
-|service| offers encryption features to protect data while in transit, at rest, and in use—safeguarding data through its full lifecycle.
+|service| offers encryption features to protect data while in transit, at rest, and in use to safeguard data through its full lifecycle.
 
-Encryption in transit
-~~~~~~~~~~~~~~~~~~~~~~~
+{+service+} Features and Recommendations for Data Encryption
+------------------------------------------------------------
+
+Features 
+~~~~~~~~
+
+Encryption in Transit
+`````````````````````
 
 Encryption in transit secures data during transmission between clients and servers, preventing unauthorized access or tampering.
 In |service|, all network traffic to {+clusters+} is protected by Transport Layer Security (TLS), which is enabled by default and cannot be disabled.
 Data transmitted to and between nodes is encrypted in transit using TLS, ensuring secure communication throughout.
 
-Encryption at rest
-~~~~~~~~~~~~~~~~~~~~
+Encryption at Rest
+``````````````````
 
 Encryption at rest ensures that all data on disk are encrypted.
 In |service|, customer data is automatically encrypted at rest.
 This process utilizes your cloud provider's disk encryption, with the provider managing the encryption keys.
 Additionally, you have the option to enable database-level encryption, allowing you to use :ref:`your own encryption keys <security-kms-encryption>`
-via AWS Key Management Service (KMS), Google Cloud KMS, or Azure Key Vault.
+with AWS Key Management Service (KMS), Google Cloud KMS, or Azure Key Vault.
 
 In-use Encryption
-~~~~~~~~~~~~~~~~~~~
+`````````````````
 
 Encryption in use secures data while it's being processed.
 MongoDB has two features for encryption in use to meet your data protection needs: Client-Side Field-Level Encryption and Queryable Encryption.
 
 Client-Side Field-Level Encryption
-```````````````````````````````````
+##################################
 
 :ref:`Client-Side Field-Level Encryption <manual-csfle-feature>` (CSFLE) is an in-use encryption capability
 that enables a client application to encrypt sensitive data before storing it in the MongoDB database.
 Sensitive data is transparently encrypted, remains encrypted throughout its lifecycle, and is only decrypted on the client side.
 
 Queryable Encryption
-`````````````````````
+####################
 
 :ref:`Queryable Encryption <qe-manual-feature-qe>` helps organizations protect sensitive data when it is queried.
 It allows applications to encrypt sensitive data on the client side, securely store it in the database, and perform equality
 and range queries directly on the encrypted data.
 This ensures protection for sensitive information without sacrificing the ability to perform queries on it.
+
+Recommendations
+~~~~~~~~~~~~~~~
+
+For development and testing environments, do not enable added encryption with :ref:`your own encryption keys <security-kms-encryption>` through AWS Key Management Service (KMS), Google Cloud KMS, or Azure Key Vault. This saves costs in your 
+non-production environments.
+
+For staging and production environments, enable added encryption with :ref:`your own encryption keys <security-kms-encryption>` through AWS Key Management Service (KMS), Google Cloud KMS, or Azure Key Vault for
+additional security.
diff --git a/source/network-security.txt b/source/network-security.txt
@@ -17,7 +17,7 @@ Network Security
 .. contents:: On this page
    :local:
    :backlinks: none
-   :depth: 1
+   :depth: 2
    :class: onecol
 
 {+service+} provides secure network configuration defaults for your
@@ -34,8 +34,8 @@ needs and preferences.
 Use the recommendations on this page to plan for the network security
 configuration of your {+clusters+}.
 
-{+service+} Features for Network Security
------------------------------------------
+{+service+} Features and Recommendations for Network Security
+-------------------------------------------------------------
 
 {+service+} enforces |tls-ssl| encryption for all connections to your
 databases.
@@ -51,8 +51,13 @@ You must explicitly enable access by one of the following methods:
 - Use |vpc| / {+vnet+} peering to add private IP addresses
 - Add private endpoints
 
+You can also use multiple methods together for added security.
+
+Features
+~~~~~~~~
+
 |tls|
-~~~~~~~~~
+```````````
 
 {+service+} enforces mandatory |tls| encryption of connections to your
 databases. |tls| 1.2 is the default protocol; you can select |tls| 1.1
@@ -62,7 +67,7 @@ or |tls| 1.0 if necessary. To learn more, see the
 <create-cluster-additional-settings>`.
 
 {+ip-access-list+}s
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```````````````````````````````
 
 As a |service| administrator, you can:
 
@@ -80,16 +85,8 @@ that expire automatically after a user-defined period.
 
 You can create one access list per project.
 
-We recommend the following as best practices:
-
-- Use temporary access list entries in situations where team members
-  require access to your environment from temporary work locations.
-- Define {+ip-access-list+} entries covering the smallest network segments
-  possible. To do this, favor individual IP addresses where possible,
-  and avoid large |cidr| blocks.
-
 Firewall Configuration
-~~~~~~~~~~~~~~~~~~~~~~
+``````````````````````
 
 If you use a firewall that blocks outbound network connections, you
 must also configure your firewall to allow your applications to make
@@ -107,7 +104,7 @@ to sharded cluster <scale-cluster-sharding>`, the
 change <scale-cluster-region>` require that you use new IP addresses.
 
 VPC/{+vnet+} Peering
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+`````````````````````````````
 
 Network peering allows you to connect your own |vpc|\s with |a-service|
 |vpc| to route traffic privately and isolate your data flow from the
@@ -127,20 +124,8 @@ peer to. {+service+} limits the number of MongoDB instances per |vpc|
 based on the |cidr| block. For example, a project with a |cidr| block of
 ``/24`` is limited to the equivalent of 273-node replica sets.
 
-We recommend the following as best practices:
-
-- To maintain tight network trust boundaries, configure security groups
-  and :aws:`network ACLs </vpc/latest/userguide/vpc-network-acls.html>`
-  to prevent inbound access to systems inside your application |vpc|\s
-  from the {+service+}-side |vpc|.
-  
-- Create new |vpc|\s to act as intermediaries between sensitive
-  application infrastructure and your {+service+} |vpc|\s. |vpc|\s are
-  intransitive, allowing you to only expose those components of your
-  application that need access to {+service+}.
-
 Private Endpoints
-~~~~~~~~~~~~~~~~~~~~~
+`````````````````
 
 A private endpoint facilitates a one-way connection from your own |vpc|
 to your {+service+} |vpc|, without permitting {+service+} to initiate a
@@ -155,6 +140,50 @@ private endpoints are available:
 - :gcp:`Private Service Connect </vpc/docs/private-service-connect>`, for
   connections from {+gcp+}
 
+Recommendations for IP Access Lists
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We recommend that you configure an {+ip-access-list+} for your API keys
+to allow access only from trusted IP addresses. 
+
+When you configure your {+ip-access-list+}, we recommend that you:
+
+- Use temporary access list entries in situations where team members
+  require access to your environment from temporary work locations.
+- Define {+ip-access-list+} entries covering the smallest network segments
+  possible. To do this, favor individual IP addresses where possible,
+  and avoid large |cidr| blocks.
+
+Recommendations for VPC/{+vnet+} Peering
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you configure |vpc| or {+vnet+} peering, we recommend that you:
+
+- To maintain tight network trust boundaries, configure security groups
+  and :aws:`network ACLs </vpc/latest/userguide/vpc-network-acls.html>`
+  to prevent inbound access to systems inside your application |vpc|\s
+  from the {+service+}-side |vpc|.
+  
+- Create new |vpc|\s to act as intermediaries between sensitive
+  application infrastructure and your {+service+} |vpc|\s. |vpc|\s are
+  intransitive, allowing you to only expose those components of your
+  application that need access to {+service+}.
+
+Recommendations for Private Endpoints
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We recommend that you set up private endpoints for all new staging and production projects to limit the extension of your network trust
+boundary.
+
+When you configure your private endpoints, we recommend that you don't
+share private endpoints across multiple projects to ensure isolation
+of configuration settings.
+
+To learn more about private endpoints
+in {+service+}, including limitations and considerations, see :atlas:`Learn About Private Endpoints in {+service+} </security-private-endpoint/>`. To learn how to set up private
+endpoints for your {+clusters+}, see
+:atlas:`Set Up a Private Endpoint for a Dedicated Cluster </security-cluster-private-endpoint/>`.
+
 Examples
 --------
 
