Security basics for a law firm AWS account

A small stick on a keyring saves no lives, but possibly a law firm account. A FIDO2 security key is currently the most robust form of multi-factor authentication: it resists phishing and man-in-the-middle attacks because it binds the counterpart cryptographically to the domain and simply cannot be talked round by a convincing fake login page. Handling it is no more complicated than plugging in a stick. Now and then it is inconvenient, for instance when it is in the other coat. For the root user (the original owner login with all rights) of an AWS account (Amazon Web Services, Amazon’s cloud platform) it is still the right choice.

Why the root user of all logins?

The root user is the login created when the account is opened, and it has unlimited rights. It cannot be fenced in by a permissions policy, because it sits above the granting of rights. Whoever takes it over takes over everything: data, configuration, logs, and the ability to remove their own traces.

That is why a simple principle stands at the start of every law firm environment. The root user gets the strongest available second factor and is retired after initial setup. After that, all work runs through individual person-bound logins, with no permanent access keys. Person-bound means every action can be attributed to a human being, which matters for later evidence at least as much as for security itself.

How do you secure an AWS account for a law firm?

Six measures form the base everything else builds on.

1. Long passwords and rotating keys. Passwords of around 32 characters from a password manager, API keys replaced at fixed intervals. A key that is never changed is a key whose compromise nobody ever notices.

2. MFA for every login, not just the root user. A single login without a second factor makes securing all the others largely pointless, because attackers get to pick the weakest point.

3. No permanent access keys in daily use. Access through time-limited sign-ins instead of key pairs that sit in a configuration file on a laptop and stay valid there even after a device change.

4. VPC endpoints instead of a NAT gateway. With PrivateLink, requests reach the AI service inside the AWS network without touching the public internet. That shrinks the attack surface and, at the same time, makes the question of which route a client secret takes answerable in the first place. One note from practice: these endpoints cost money continuously, even when unused. They therefore belong in the infrastructure description and in the regular review, otherwise the firm pays for a path nobody uses any more.

5. Your own keys for encryption. With self-created KMS keys (encryption keys in the AWS key service, held in the firm’s own account) control over encryption stays in your own account, including the record of who used them for what.

6. Budget and cost alerts. The point that looks most banal is also the best early warning system. Stolen credentials are, as a rule, not used to read case files but to consume computing power. A sudden rise in costs is therefore often the first visible sign of a breach, frequently well before anything conspicuous in the content. A cost alert is thus not a commercial instrument but a security one.

The unpleasant part: following up

All six points share a weakness. They are set up once and then invisible, and invisible measures decay. A second factor gets left out “temporarily” for a new login. A key is created for one analysis and never deleted. A cost alert fires, someone acknowledges it, nobody chases the cause.

That is why each of these measures needs a date and a person responsible, because the state of an account without regular review is only an assumption. A short, fixed round at a manageable interval is enough for a small firm: who has access, which keys exist, which alert has come in since last time. It is the same idea as deadline control, applied to infrastructure. It is the same sort of recurring work that suits a non-billable first step.

What this list is not

It is not exhaustive. It is the base on which the layer that actually matters under professional conduct law is built: the firm-wide enforcement of EU hosting, the logging of model calls without recording the content, and the contract with the provider under § 43e BRAO.

What stands out is how unspectacular the individual measures are. No point on this list demands specialist knowledge, and several are done in an afternoon. The difference between a hardened and an unhardened firm environment does not come from sophistication but from the decision to take these steps before the first productive use rather than after the first incident.

The practical advice I give firms is therefore plain. Hardening belongs in the setup, not in the remediation. Retiring a root user after three months of work has already run through it is far more laborious than doing it right the first time.