Software Requirements

Modern software architecture has evolved from monolithic applications to distributed systems built on microservices, enabling greater scalability, flexibility, and resilience. In a microservices architecture, functionality is decomposed into small, independently deployable services that communicate with each other to deliver the overall service. This modular approach allows for scaling individual components based on demand, ensuring consistent performance even during peak demand.

Core Microservices that make up Nullafi Shield

Web Management Console

One instance of the Nullafi Shield container configured as the Web Management Console is required. This is where Administrators configure application integrations and create policy, and view status and reporting from the system. Access to the Web Management Console is via web browser. The configured NULLAFI_HTTP_CUSTOM_DOMAIN should resolve to the host running this container. While it might be possible to run multiple instances simultaneously for High Availability, that is generally not needed. The service itself is not very resource intensive and even a small host will suffice for tens or hundreds of administrators.

Alert Node

A Nullafi Shield container configured as an Alert Node will use information from the Configuration Database to run queries against the Activity Database on the appropriate schedule and distribute alerts as designated by the policy. No inbound connections are required to an Alert Node.

Enforcement Nodes

Nullafi Shield containers configured as Enforcement Nodes are the primary workhorses of the overall service. These can be either ICAP or API servers, but either way, they are where data is scanned and policy enforced. ICAP nodes typically receive requests on port 1344 (or 11344 for SSL encrypted connections) and API nodes on port 443, but these are of course configurable. When designing a large Nullafi Shield service, enforcement nodes are typically distributed across regions -- as close to end users as possible.

Configuration Database

The Nullafi Shield service uses Redis, an in-memory caching database, to store configuration and make it available to all of the other microservices that need it. Examples in this Shield documentation use a containerized instance of Redis running on the same host as the Web Management Console, but that is not necessary. For more information about deploying Redis at scale, see their documentation site.

Activity Database

The Nullafi Shield service uses Elasticsearch, a distributed search and analytics engine designed for fast and scalable data retrieval, to store Activity and Alert data. This database records events as user traffic flows through the system, such as what data types have been identified and whether or not they were redacted based on policy. Similar to the Configuration Database, examples in this Shield documentation demonstrate deploying a containerized, single-instance Elasticsearch cluster. For full production deployment, we strongly suggest you consider a multi-node cluster. The Shield service does not require a dedicated Elasticsearch cluster. If you maintain a cluster for other purposes that has enough spare capacity, it is perfectly reasonable to use it rather than deploying a new one for use with Nullafi Shield.

External services and integrations

ICAP Client

When Nullafi Shield is deployed as an ICAP server, it requires an ICAP client to submit user traffic to the server for inspection. Any typical proxy server can be configured as an ICAP client for Request and Response Modification. In many cases, existing network infrastructure such as a Secure Web Gateway is already processing user traffic and can be configured as an ICAP client. If user traffic is not already being routed through a device or service that can be an ICAP client, a new proxy should be deployed at the same time as the Nullafi Shield service as a means of routing traffic for inspection.

Proxy Considerations

to inspect HTTPS traffic, the proxy must have a certificate trusted by end user client devices. See the documentation for your security device or software acting as an ICAP client for details.
In cases where a proxy does not support ICAP, configuring proxy forwarding (also called proxy chaining) to an upstream proxy that does is a good option. Here is a link to Zscaler's documentation as an example.
Many Secure Web Gateways perform authentication in order to implement user-based policies. In this case it is probably more efficient to add the user information to the ICAP headers rather than configure Shield to repeat the authentication process.

API Client

When Nullafi Shield is deployed as an API server, it accepts REST API calls to the /scan or /scan-dynamic endpoints to perform data classification and redaction. Full Swagger documentation is available through the Web Management Console at https://<Shield hostname or IP>/swagger/index.html

User/Group Directory

When Nullafi Shield is integrated with your user directory, it can use User or Group information to selectively apply Policy. For example, "redact credit card numbers for members of the Developers group." Without directory integration, Shield can be configured with global policy that applies to all users equally. Directory integration can be accomplished via headers inserted into ICAP connections by the proxy, or via SAML authentication, where Shield acts as a client to your Identity Provider.

External Activity Logging

Data stored in the Activity Database (see core services above) can be viewed and searched inside the Web Management Console. Many organizations, however, utilize centralized logging systems and would like to include data from Nullafi Shield in their SIEM systems to be correlated with other event data. Shield instances can be configured to send log data via syslog using several NULLAFI_SYSLOG_ACTIVITY_ environment variables. We recommend running a syslog container on the same host as the Shield container, and using the robust capabilities of software such as syslog-ng for routing data to your centralized tooling system.