How Leading Tech Companies Audit and Control Ops Permissions

Question: Companies like BAT and banks have servers with highest privileges; how do they audit and supervise operational permissions?

Below is the answer from Zhihu user @Zhang Cheng, who previously worked in operations at AppAnnie.

Background: AppAnnie has separate operations and security teams. Both have the same production access rights, while most developers lack direct host access; only a few leaders can access, and only after security group approval for urgent issues.

Specific measures:

1. Everyone (operations & security) logs into servers with personal accounts; root login is prohibited. All commands, including those executed via sudo, are recorded in system logs with SUDO_USER, allowing identification of who performed each action and when.

All hosts run OSSEC to monitor command logs. Sensitive actions (e.g., sudo, rm, file accesses) trigger immediate email alerts to both security and operations mailing lists, ensuring continuous supervision. Bypassing this monitoring is extremely difficult.

2. Database hosts have stricter policies. A firewall rule cuts off SSH sessions exceeding 100 KB of traffic, limiting the amount of data that can be exfiltrated even if a user attempts a full

SELECT *

dump, while all commands remain under collective supervision.

3. When developers need production data, they request the security team. After approval, the operations team writes a script to dump the data, masking sensitive fields (e.g., replacing them with random characters). The script is reviewed and approved by security before execution, and the resulting dump is transferred back using a temporary firewall rule.

Key takeaways:

1. Principle of least privilege: Even with root (sudo) rights, execution of unapproved commands and access to sensitive data are prohibited unless absolutely necessary.

2. Mutual supervision: Operations, security, and the CTO (who receives alerts but has no production account) all monitor command logs. Misconduct would require collusion among all six members, making it practically impossible.

AppAnnie’s approach incurs overhead—security‑related processes are lengthy, and code involving encryption must be reviewed by security before deployment. The security team is small (one senior member plus interns), leading to delays of up to a week for reviews, but the company accepts this trade‑off for safety.

Finally, the author stresses that corporate culture and security awareness are crucial; many Chinese companies rely on personal trust rather than systematic controls, which is risky, and often prioritize efficiency over security.