HCL Domino and Defensive API Architecture

Image Generated by Imagen in Google Gemini

HCL Domino's REST APIs unlock powerful integration capabilities, enabling data exchange with external systems and enhancing business workflows. However, exposing these APIs directly to the internet introduces significant security risks. To mitigate these risks, this blog post explores the concept of 'Defensive API Architecture.' 

This approach involves implementing a multi-layered security strategy that isolates your core Domino environment, controls data access, and minimizes the impact of potential attacks. By adopting Defensive API Architecture, you can leverage the benefits of Domino's REST APIs while maintaining the integrity and security of your critical data."

Domino REST APIs are Awesome!

If you're not already using Domino's REST APIs then you're missing a treat. These APIs represent a major advancement in Domino, reflecting HCL's ongoing innovation.

REST APIs in Domino allow you to do lots of things but the main ones are: 

• View Records
• Add, Modify and Delete Records
• Run Agents to execute server side tasks.

Being APIs, this means that these calls can be made from anywhere outside the server. This makes it easy to exchange data with other systems or with your customers but there's always the risk that they could leave your data exposed. 

In this post, I want to talk about overall architecture, so I won't cover mundane topics like access control lists (ACLs) and passwords. I would expect that everyone already knows that. 

If you're using REST APIs, you are likely in one of two scenarios;

1. Exchanging Data with a restricted list of systems
2. Exchanging Data with the world (or at least, an expanding user base). 

The Unspoken Rule about Production Systems

Before I get into detail about architecture, there is one unspoken rule about production systems that I want to reiterate:

Never expose your production system to the outside world.

Direct exposure increases vulnerability to attacks, data breaches, and system instability. It seems pretty simple but it's surprising how quickly this rule gets forgotten. 

Exchanging Data with a Restricted List of Systems

From a security point of view, this is the easiest scenario. You simply get a list of all of the endpoints (ip addresses) that will access your system and you lock your REST API server's IP address and ports down to only those IP Addresses. 

I'm assuming that in this case, you either own these systems or you have significant trust in these systems. More importantly, you need to know for sure that you know the volumes of requests to expect and can throttle them if needed. If you are going to do more than just read production systems, you might want to lean on some of the techniques I talk about under exchanging data with the world.

If your firewall is well managed and traffic is being appropriately monitored, unusually high volumes from specific IP addresses should be detectable and those links can be closed or filtered as needed. 

Exchanging Data with the World

If you're exchanging data with the world, it can be a little more tricky to shape traffic because you never quite know where it is going to come from. In the case of a distributed denial of service (DDoS) attack, that traffic could come from a myriad of sources and you could  be left with no other option than to temporarily withdraw your services and/or move the server behind cloud filtering services, such as CloudFlare (which I wholeheartedly recommend for domino web servers in any case).

When exchanging  data with the world, I don't recommend using your domino server to communicate directly with the unfiltered internet via API. This is not because of Domino's security, which is very good, it's simply because Domino is a very complex and capable application. We used to refer to it as the "swiss army knife" of servers (and applications) because it does so many diverse things. This means that there are always going to be alternative methods to access things that need to be tightened up. If you're going to expose data to the web, it's better to use a dumb service with limited capabilities and almost no connection to your production data. 

Here's how we did it. 

• Create a your REST APIs on Domino in the normal way but ensure that your rest API only exposes the data that is actually needed externally.  If there are fields in the database that aren't required for the process, don't expose them in the API. 
• Get a database server that can connect to a scalable API - In our case, we used SQL on Azure. We'll refer to this as the "risk environment".
• Use the techniques in exchanging data with a restricted list of systems to get Domino to securely share data via API with only your external server. This may be uni or bidirectional depending on requirements.
• You will need to add a function to convert data from the Domino APIs to SQL. Initially we were using HCL's Foundry service but this was complex to maintain and very expensive in terms of licensing and infrastructure. We ended up replacing this with an in-house custom app written by one of our developers in a couple of weeks. 
• Use the Risk Environment's API to expose the data to your global customer base.

Why this is Secure

At this stage, all the data in your Risk Environment is a "read-only" copy of production. We haven't discussed "writing" yet. In the even that your risk environment becomes compromised, you need only clear the data out from the SQL tables and re-run the API to SQL Agent. Depending on the amount of data in the system, the permitted outage windows and the timeliness required, you might want to run a process like this nightly. It's recommended that your process migrates to a non-production database in the risk environment first, then does relevant checking. If checks are good, the current production tables are migrated to a backup table and the new data is loaded. 

In the event that your risk environment is attacked, you can scale the API as required without impacting your real production domino servers. If there is a data compromise, you can easily erase and replace the data. If the risk environment is hacked, you need only change a couple of domino passwords (just in case) and there will be no repercussions in production. This is because the Domino APIs permit only read-only access to the production database. 

A Note on Adding Data

I keep talking about how the Domino APIs are permitting Read-Only access to your production environment but what if you want external parties to update your data via API?

1. You should still have your production database and API only permitting READ-ONLY access.
2. You can create a second database that allows depositor access. 
3. When records are written via the API, a change (Add, Delete or Change) record is created in the Domino "Add" database.
4. You can then write an agent to validate those records and apply those changes to production. This will provide you with a log of all changes that have occurred and will allow you to store approved and rejected changes in a way that preserves the integrity of your data.
5. You can run the agent as often as needed depending upon the system requirements. Though you will not achieve entirely "immediate" results in the risk environment.