Hacker News Reader

Hacker News

Comment by shevy-java | Hacker News Reader

Parent Full thread

shevy-java

You are actually right, I didn't think of this before.

How can they ensure that nobody else did any tampering?

It seems RubyCentral did not think this through completely.

View on HN

> It seems RubyCentral did not think this through completely.

this is the problem when you fire all the maintainers who do anything

You can set up EC2 instances in a way that that just having AWS root access doesn't give you ssh/console access to the instances. You can still do things like Run Command but that leaves a very obvious trail (although even this is preventable with enough effort).

Also you can enable cloudtrail log validation which can ensure you know if you're looking at tampered logs or not.

Really it all depends on how their accounts are set up. Unless you know the operational details you can't make a call here.

I've run a multi-million dollar/year AWS Org for the last decade or so and setting things up this way is kind of brass tacks.

So you almost certainly know that a lot of IaC tooling has terrible defaults like enable_log_file_validation being set to false. Based on the quality of their credential management and what else you can read from this blog post, how much would you wanna wager they did it right?

I assume everyone is professional until they prove otherwise.

Based on how things have been described on both sides, it actually sounds like they do a pretty good job. Oversights happen -- we're all human -- and this access was already limited to a small single-digit number of people. Given the history, it's reasonable that Arko would have had this high of a level of access and the oversight was in forgetting that when removing him.

Also it's reasonable to assume that people with that access wouldn't do something criminal/malicious, and if they did, while annoying, the situation is very easily recoverable. Especially if you're using IaC tooling as you mentioned.

If you're already taking the position that Ruby Central are "the bad guys" it's easy to assume that they're doing everything wrong, but that would be a mistake.

I believe this is a scenario where AWS recommends multiple accounts.

1. Create another "management" AWS account, and make your other AWS account a child to that.

2. Ensure no one ever logs in to the "management" account, as there shouldn't be any business purpose in doing so. For example, you should require a hardware key to log in.

3. Configure the "management" account to force children account to enable AWS Config, AWS CloudTrail, etc. Also force them to duplicate logs to the "management" account.

Step 2 is important. At the end of the day, an organization can always find a way to render their security measures useless.

2) Surely, someone needs access to the account. How do you prevent those with access from using it? Security feels like turtles all the way down where you ultimately have to trust a few people to do the right thing.

The only reason someone would need access to the management account would be maintaining child accounts and IAM roles or reviewing logs, none of which should need root.

Reply on news.ycombinator.com