[DOCS] Merges security overview pages (#49342)

docs/reference/redirects.asciidoc

@@ -1010,3 +1010,8 @@ See <<ref-ad-settings>>.
 === Mapping Active Directory users and groups to roles
 
 See <<ad-realm-configuration>>. 
+
+[role="exclude",id="how-security-works"]
+=== How security works
+
+See <<elasticsearch-security>>.

x-pack/docs/en/security/authentication/internal-users.asciidoc

@@ -11,4 +11,4 @@ For this reason, they cannot be used to authenticate against the API and there
 is no password to manage or reset.
 
 From time-to-time you may find a reference to one of these users inside your
-logs, including <<auditing, audit logs>>.
+logs, including <<auditing,audit logs>>.

x-pack/docs/en/security/how-security-works.asciidoc

@@ -1,50 +0,0 @@
-[role="xpack"]
-[[how-security-works]]
-== How security works
-
-An Elasticsearch cluster is typically made out of many moving parts. There are
-the Elasticsearch nodes that form the cluster and often Logstash instances,
-Kibana instances, Beats agents, and clients all communicating with the cluster.
-It should not come as a surprise that securing such clusters has many facets and
-layers.
-
-The {stack-security-features} provide the means to secure the Elastic cluster
-on several levels:
-
-  * <<setting-up-authentication,User authentication>>
-  * <<authorization,User authorization and access control>>
-  * Node/client authentication and channel encryption
-  * Auditing
-
-[float]
-=== Node/client authentication and channel encryption
-
-The {security-features} support configuring SSL/TLS for securing the
-communication channels to, from and within the cluster. This support accounts for:
-
-  * Encryption of data transmitted over the wires
-  * Certificate based node authentication - preventing unauthorized nodes/clients
-    from establishing a connection with the cluster.
-
-For more information, see <<encrypting-communications, Encrypting Communications>>.
-
-The {security-features} also enable you to <<ip-filtering, configure IP Filters>>
-which can be seen as a light mechanism for node/client authentication. With IP
-filtering, you can restrict the nodes and clients that can connect to the
-cluster based on their IP addresses. The IP filters configuration provides
-whitelisting and blacklisting of IPs, subnets and DNS domains.
-
-
-[float]
-=== Auditing
-When dealing with any secure system, it is critical to have a audit trail
-mechanism set in place. Audit trails log various activities/events that occur in
-the system, enabling you to analyze and back track past events when things go
-wrong (e.g. security breach).
-
-The {security-features} provide such audit trail functionality for all nodes in
-the cluster. You can configure the audit level which accounts for the type of
-events that are logged. These events include failed authentication attempts,
-user access denied, node connection denied, and more.
-
-For more information on auditing see <<auditing>>.

x-pack/docs/en/security/index.asciidoc

@@ -10,7 +10,6 @@ IP filtering, and auditing.
 
 * <<elasticsearch-security>>
 * <<configuring-security>>
-* <<how-security-works>>
 * <<setting-up-authentication>>
 * <<saml-guide>>
 * <<oidc-guide>>
@@ -28,7 +27,6 @@ IP filtering, and auditing.
 
 include::overview.asciidoc[]
 include::configuring-es.asciidoc[]
-include::how-security-works.asciidoc[]
 include::authentication/index.asciidoc[]
 include::authorization/index.asciidoc[]
 include::auditing/index.asciidoc[]

x-pack/docs/en/security/overview.asciidoc

@@ -5,6 +5,11 @@
 <titleabbrev>Overview</titleabbrev>
 ++++
 
+An {es} cluster is typically made out of many moving parts. There are the {es}
+nodes that form the cluster and often {ls} instances, {kib} instances, Beats
+agents, and clients all communicating with the cluster. It should not come as a
+surprise that securing such clusters has many facets and layers.
+
 Security protects {es} clusters by:
 
 * <<preventing-unauthorized-access, Preventing unauthorized access>>
@@ -12,7 +17,7 @@ Security protects {es} clusters by:
 * <<preserving-data-integrity, Preserving the integrity of your data>>
   with SSL/TLS encryption.
 * <<maintaining-audit-trail, Maintaining an audit trail>>
-  so you know who's doing what to your cluster and the data it stores.
+  so you know who's doing what to your cluster and the data it stores.  
 
 [float]
 [[preventing-unauthorized-access]]
@@ -26,7 +31,7 @@ the person named _Kelsey Andorra_ can sign in as the user `kandorra`. The
 you to quickly password-protect your cluster. If you're already using LDAP, 
 Active Directory, or PKI to manage users in your organization, the
 {security-features} are able to integrate with those systems to perform user
-authentication.
+authentication. 
 
 In many cases, simply authenticating users isn't enough. You also need a way to
 control what data users have access to and what tasks they can perform. The
@@ -36,9 +41,12 @@ role-based access control mechanism (a.k.a RBAC) enables you to specify that the
 user `kandorra` can only perform read operations on the `events` index and can't
 do anything at all with other indices.
 
-The {security-features} also support IP-based authorization.
-You can whitelist and blacklist specific IP addresses or subnets to control
-network-level access to a server.
+See <<setting-up-authentication>> and <<authorization>>.
+
+The {security-features} also enable you to restrict the nodes and clients that
+can connect to the cluster based on <<ip-filtering,IP filters>>. You can
+whitelist and blacklist specific IP addresses, subnets, or DNS domains to
+control network-level access to a cluster.
 
 [float]
 [[preserving-data-integrity]]
@@ -48,8 +56,9 @@ A critical part of security is keeping confidential data confidential.
 {es} has built-in protections against accidental data loss and
 corruption. However, there's nothing to stop deliberate tampering or data
 interception. The {stack-security-features} preserve the integrity of your
-data by encrypting communications to and from nodes. For even	
-greater protection, you can increase the <<ciphers,encryption strength>>.
+data by encrypting communications to, from, and within the cluster. See
+<<encrypting-communications>>. For even	greater protection, you can increase the
+<<ciphers,encryption strength>>.
 
 [float]
 [[maintaining-audit-trail]]
@@ -57,7 +66,10 @@ greater protection, you can increase the <<ciphers,encryption strength>>.
 
 Keeping a system secure takes vigilance. By using {stack-security-features} to
 maintain an audit trail, you can easily see who is accessing your cluster and
-what they're doing. By analyzing access patterns and failed attempts to access
-your cluster, you can gain insights into attempted attacks and data breaches.
-Keeping an auditable log of the activity in your cluster can also help diagnose
-operational issues.
+what they're doing. You can configure the audit level, which accounts for the
+type of events that are logged. These events include failed authentication
+attempts, user access denied, node connection denied, and more. By analyzing
+access patterns and failed attempts to access your cluster, you can gain
+insights into attempted attacks and data breaches. Keeping an auditable log of
+the activity in your cluster can also help diagnose operational issues. For more
+information, see <<auditing>>.