Minecraft and Identity Management

What an Identity Management guy learned from managing a world populated by tweens and teens…

“Lava and TNT is covering the entire spawn, dad! Can you fix it?”

I help my 12-year-old son run a Minecraft server for his friends, as well as random strangers (500+ at last count). Players point their Minecraft game at his server and work collaboratively (or so we hope) with others to build things, chat, and otherwise have fun.

In the span of two years, there’s been a lot of learning when it comes to managing a system where the bulk of the users have pre-teen or early teen levels of maturity.

What Could Possibly Go Wrong?

Apparently on a server loaded with pre-teen users, there’s actually a LOT that go wrong…frequently.

In addition to my Saturday mornings of cleaning up lava and TNT (CoreProtect is your friend), I’ve needed to unban dozens of legitimate users, revoke privileges from griefers who have decided to destroy parts of the world, and kill off entire populations of zombies, creepers, and other creatures that were placed with the intent to DDoS the server with lag.

While on the surface these all seem to be different problems, they all ultimately come down to the wrong people having too much access and a lack of visibility into who has access to do what.

Who can you Trust?

To be clear, this access generally started with one person (my son), but as a server grew, this power got distributed to other helpers. These helpers get roles like Admin, Mod, Builder, etc… that give them a range of powers.

Minecraft servers support a notion of privilege systems. These systems allow you to very granularly define what each of these groups have access to do. For example, the Builder role might have access to make broad changes to the world by placing blocks in bulk using the WorldEdit, while users in the Mod role may have access to kick a player off the server or ban them. Figuring out which role grants access to what privileges involves manually sifting through pages of roles and permissions in a text file. Users can also have permissions that override the ones defined in their roles or have their roles and permissions restricted to only certain worlds or regions within the server.

If you’ve ever visited a multi-player Minecraft server, you’ll notice that the chat logs are inundated with kids asking others for all kinds of elevated access. If you’ll only make them a Mod, they’ll be your friend for life, bring all their friends to your server, build great things, and help you keep everything running smoothly. They’re friends with so-and-so, who runs the biggest Minecraft server you can imagine, and she will get so-and-so to send people to your server as well.

This is all bulls***. You’re much better off giving your password to the guy on the phone claiming to be from IT or clicking a phishing link.

Apparently, when kids hear this kind of thing, they start giving everyone crazy levels of access without considering the consequences. At one point when things were particularly out of control on the server, I audited user permissions and found that approximately half the active users had some level of privileged access. There was actually a network effect of kids giving it to other kids.

To make things worse, plugins all have their own permissions. Some of these permissions are quite powerful and allow players to change large parts of the world. It’s not always obvious when such privileges have been granted until they are granted to the wrong people — who then take advantage of it.

Who is this Really?

The Minecraft game itself costs money (~$27). Many families buy a single copy that gets shared by everyone in the family. Some kids even share their software with other friends that may not have bought a copy. All of this is done by sharing a single Minecraft login/password.

This means that even if you’ve got a great contributor who is building great things and interacting with a level of maturity well beyond their years…five minutes later a completely different kid could be accessing your server with the exact same account…and this kid could be a disaster!

Not only that, but nearly everyone who does something bad to your sever will claim that it was not really them that did it at all…but their terrible brother/sister/friend/etc… Hackers are frequently invoked. Those of you with multiple kids (or dysfunctional teams) know exactly what I’m talking about.

It’s like asking who left up the toilet seat or ate the last cookie — maybe a ghost?

Regardless of who did it, the damage is done and you’re left cleaning up the mess.

Enterprise Software is Different, Right?

Your typical enterprise is running hundreds or thousands of applications. Each of these systems also has roles and permissions that determine who gets access to which data or functions. Ideally, the security on these systems is being managed in a way that is different from the way my son runs his Minecraft server.

IT and the business need to understand some fundamental things about the users of mission critical systems:

• Who has access to which systems, functionality, and data?
• How is this access requested and approved?
• Who is certifying that this access continues to be appropriate?
• What users have toxic permission combinations (e.g. create/pay their own POs)?
• Who has highly privileged access (e.g. super-user) and what are they doing with it?

This is where Identity Governance comes into play.

Identity Governance solutions connect to various systems in the enterprise to manage accounts, roles, and entitlements for users.

When an employee joins the company, they get a standard set of privileges for their role in the enterprise. This might be things like sending email or submitting expense reports. Additional privileges can be easily requested and approved as appropriate by the business and IT. Finally, when an employee leaves the company, their accounts and privileges are centrally revoked across all of these systems.

Lack of proper controls open enterprise applications to various insider threats. Additionally, over-privileged accounts are a goldmine for hackers that have already gained basic access via common attacks like phishing and malware.

Avoiding Lava and TNT

Hooking up an Identity Governance solution to a Minecraft server is a bit overkill — though don’t think I didn’t consider it.

Instead, I simply went user-by-user, role-by-role to limit everyone’s access to the bare minimum. We then selected a few users that would be given the ability to do more privileged things, but didn’t allow these users to further delegate their privileges. Additional plugins were added that allow for tracking and rollback if these permissions were abused (similar to privileged session recording).

Cleaning things up with 500 users in a half-dozen roles on a single, relatively simple system took several hours.

Scaling this manual process up to tens of thousands of users, thousands of roles, and hundreds of systems without the benefit of automation would have been completely impossible without cutting corners and reducing overall security.

That said, in the case of the Minecraft server, this significantly improved the stability of the server and eliminated some of the large-scale griefing that was taking place.

About the Author

Clayton Donley is the Vice President of Product Management for Oracle’s Identity Management and Mobile Security products. You can follow him on Twitter at @cdonley.