118 lines
4.8 KiB
Plaintext
118 lines
4.8 KiB
Plaintext
[[secure-cluster]]
|
|
= Secure the {stack}
|
|
|
|
[partintro]
|
|
--
|
|
|
|
The {stack} is comprised of many moving parts. There are the {es}
|
|
nodes that form the cluster, plus {ls} instances, {kib} instances, {beats}
|
|
agents, and clients all communicating with the cluster. To keep your cluster
|
|
safe, adhere to the <<es-security-principles,{es} security principles>>.
|
|
|
|
<<configuring-stack-security,Start the {stack} with security enabled>> or
|
|
<<manually-configure-security,manually configure security>> to
|
|
secure {es} clusters and any clients that communicate with your clusters. You
|
|
can password protect access to your data as well as enable more advanced
|
|
security by configuring Transport Layer Security (TLS). This additional layer
|
|
provides confidentiality and integrity protection to your communications with
|
|
the {stack}. You can also implement additional security measures, such as
|
|
role-based access control, IP filtering, and auditing.
|
|
|
|
Enabling security protects {es} clusters by:
|
|
|
|
* <<preventing-unauthorized-access, Preventing unauthorized access>>
|
|
with password protection, role-based access control, and IP filtering.
|
|
* <<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.
|
|
|
|
TIP: If you plan to run {es} in a Federal Information Processing Standard (FIPS)
|
|
140-2 enabled JVM, see <<fips-140-compliance>>.
|
|
|
|
[discrete]
|
|
[[preventing-unauthorized-access]]
|
|
== Preventing unauthorized access
|
|
|
|
To prevent unauthorized access to your {es} cluster, you need a way to
|
|
_authenticate_ users in order to validate that a user is who they claim to be. For
|
|
example, making sure that only the person named _Kelsey Andorra_ can sign
|
|
in as the user `kandorra`. The {es-security-features} provide a standalone
|
|
authentication mechanism that enables 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} integrate with those systems to perform
|
|
user authentication.
|
|
|
|
In many cases, authenticating users isn't enough. You also need a way to
|
|
control what data users can access and what tasks they can perform. By enabling
|
|
the {es-security-features}, you can _authorize_ users by assigning access
|
|
privileges to roles and assigning those roles to users. Using this role-based
|
|
access control mechanism (RBAC), you can limit the user `kandorra` to only
|
|
perform read operations on the `events` index restrict access to all other
|
|
indices.
|
|
|
|
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
|
|
block and allow specific IP addresses, subnets, or DNS domains to
|
|
control network-level access to a cluster.
|
|
|
|
See <<setting-up-authentication,User authentication>> and
|
|
<<authorization,User authorization>>.
|
|
|
|
[discrete]
|
|
[[preserving-data-integrity]]
|
|
== Preserving data integrity and confidentiality
|
|
|
|
A critical part of security is keeping confidential data secured.
|
|
{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} use TLS to preserve the _integrity_
|
|
of your data against tampering, while also providing _confidentiality_ by
|
|
encrypting communications to, from, and within the cluster. For even greater
|
|
protection, you can increase the <<ciphers,encryption strength>>.
|
|
|
|
See <<configuring-stack-security,Configure security for the {stack}>>.
|
|
|
|
[discrete]
|
|
[[maintaining-audit-trail]]
|
|
== Maintaining an audit trail
|
|
|
|
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. 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.
|
|
|
|
See <<enable-audit-logging,Enable audit logging>>.
|
|
|
|
--
|
|
|
|
include::es-security-principles.asciidoc[]
|
|
|
|
include::configuring-stack-security.asciidoc[]
|
|
|
|
include::security-manual-configuration.asciidoc[]
|
|
|
|
include::securing-communications/update-tls-certificates.asciidoc[]
|
|
|
|
include::authentication/overview.asciidoc[]
|
|
|
|
include::authorization/overview.asciidoc[]
|
|
|
|
include::auditing/index.asciidoc[]
|
|
|
|
include::using-ip-filtering.asciidoc[]
|
|
|
|
include::ccs-clients-integrations/index.asciidoc[]
|
|
|
|
include::operator-privileges/index.asciidoc[]
|
|
|
|
include::troubleshooting.asciidoc[]
|
|
|
|
include::limitations.asciidoc[]
|