Interface security: accounts, keys and permissions

When we look at an existing connection in a company, we very often find the same pattern: there is exactly one account for the interface, that account holds administrative rights in the target system, it was created at go-live and has been unchanged ever since. The password sits in a settings file on the server, additionally in a script somebody wrote for a special case, and frequently in a message from the rollout phase that is still sitting in several mailboxes.

This pattern does not arise from carelessness but from how a rollout works. During the first connection the goal is simply that data arrives at all. An account with broad rights saves questions in that phase: no error messages about missing permissions, no waiting for the vendor, no discussion about which field may be read. Once the transfer runs, the question disappears from view because it no longer shows up in daily work. An account with too many rights behaves quietly — it works, and it works exactly as well as a narrow one.

The consequences appear later and rarely on the day of the incident. Whoever obtains these credentials can usually do whatever the target system allows: read, change, delete, export. Because the same account serves several processes, it is impossible afterwards to say which action came from which program. And because the password is stored in several places, it cannot simply be changed: every change stops an unknown number of processes. That is the point where a security topic turns into an operational one — an account you cannot revoke without halting the business is not a managed account.

The question of where a key is kept is answered wrongly more often than the question of which method is used. Typical locations in existing installations: a settings file next to the program, a script in the task scheduler, a text document on a shared drive, a message in the managing director's mailbox, a note in the server cabinet. Each of these is individually explainable. Together they create a state in which nobody can say how many copies exist.

An orderly storage arrangement need not be a major purchase. Four properties matter: there is exactly one place that counts as authoritative; access to it is limited to named people; it is traceable who retrieved something and when; and there is a procedure for the case where the responsible person cannot be reached. These four points can be met with simple means as long as they are written down. Where the connection is looked after externally, the storage arrangement belongs in the agreement covering ongoing IT operations, not in a verbal understanding.

The practical benefit of this order does not show in normal operation but on two days: the day somebody leaves the company, and the day there is a suspicion of an incident. On both days the only relevant question is which accounts are affected and how quickly they can be changed. Anyone who can answer that in minutes has dealt with the larger part of the topic.

The principle is old and simple: an account gets exactly the rights the process needs and none beyond that. The German federal information security authority (BSI) describes this principle in its baseline protection modules as one of the load-bearing rules for handling permissions. In practice it rarely fails on understanding, but on the fact that nobody has written down what the process actually needs.

Implementation therefore starts not in the permission system but with a list of operations. Which data does the connection fetch? Which does it write back? Does it need to delete? Does it need master data or are transaction records enough? That list is produced anyway when a connection is properly described, and it doubles as the basis for granting rights. Where no such description exists, going through a process analysis is the faster route, because otherwise the guesswork starts over with every permission error.

A simple approach helps during the changeover: set the rights narrowly at first, run the connection in test mode for a week, and assess each permission error individually instead of widening the scope wholesale. The effort is manageable and occurs once. What remains afterwards is an account whose scope of rights is justified and can be explained during a later review.

Without a log it is impossible to establish after a problem what was transferred and what was not. A log is therefore not an add-on but part of the connection. At the same time it is the place where credentials most often end up unintentionally — not by intent, but out of convenience during troubleshooting.

The classic case: to analyse a sign-in problem, the complete request is written out, including the credentials it carries. The setting stays active because nobody reverses it after the fix. From then on the key appears in every log file, is backed up daily and thus sits in every backup of the following months. A password change then only helps partly, because the old backups still exist. What once appears in a log does not disappear from the backups again.

A usable log contains timestamp, connection, account used, the operation concerned, result and duration. It contains no passwords, no keys and no complete records with personal content. Instead of the key, its identifier is written — that keeps it traceable which key was in use without storing the key itself. How long logs are kept and who may view them belongs in the process documentation and should not be left to whatever the default setting happens to be.

Many connections in mid-size companies are maintained externally, by the vendor of a system or by an IT services firm. That is unproblematic as long as it is clear who owns which accounts. It becomes unclear when the credentials sit exclusively with the provider and the company itself has no access to them. In an emergency there is then no way to block an account at short notice.

Four points therefore belong in the agreement, in writing: which accounts exist and who owns them? Where are the credentials kept and does the company itself have access? Who reports a suspicion to whom, and within what time? And what happens to accounts and copies of the data when the cooperation ends? The last point is forgotten most often and is the one with the longest aftermath.

Surveys by Bitkom and the Association of German Chambers of Commerce and Industry (DIHK) on the state of IT security regularly show that smaller and mid-size companies less often have responsibilities defined in writing than larger organisations. The effort for such a definition is small — it is a page of text, not a project. The difference shows on the one day it is needed.