User Data Access¶
The Punch enforces a 3-Tiers network architecture where the data is in the deeper network zones. Users interact with the consolidated data products through well-protected endpoints. This is illustrated next:
The data is protected from the external accesses first by authentication, then by application. This is a perimetric protection. Firewalls, proxies and sensors are configured and monitored to supervise access and potential abnormal behaviours.
The punch lets you choose among two solutions. One is based on the opendistro plugin. Refer to the Data protection with opendistro chapter. The other only leverages apache reverse proxies and its modsecurity plugin. Refer to the Data protection with Modsecurity chapter.
External Data Ingestion¶
The punch is also in charge of collecting and ingesting data from remotes sites to the central punch instance. To prevent sniffing at the platform outbound interface, the punch provides SSL capabilities at the level of its input and output nodes. This makes it possible to safely collect and ship data from remote sites to the central punch instance.
Several SSL provider and level of encryption are available. The detailed description of the components at play is available here:
- Syslog Input configuration
- Syslog Output configuration
- Lumberjack Input configuration
- Lumberjack Output configuration
Internal Data Management¶
Once ingested, the data at rest still has to be protected from unwanted accesses and processings. The punch provides various mechanisms to enforce multi tenancy data protection. An authorized user can only access the data from its tenant.
Kibana has suffered from several vulnerabilities since the last three years.
The punch provides a logical segregation between each kibana instances using a chroot. Each kibana process runs in a dedicated jail. Should one kibana be exploited, the attacker can not access to the others.
To enable the feature, update the kibana section of your punchplatform.properties with the required chroot settings.
Protecting Kibana is not enough, you are likely to require to also protect your elasticsearch in a way to enforce confidentiality, and prevent internal users to access unwanted data.
To ensure the integrity of the logs, the punch can deploy a specific configuration based on hash generation, strongbox and check verification channels. A model can be sent on demand - ask firstname.lastname@example.org