How Leading Companies Stop Insider Data Theft: Real Ops & Security Practices

In today’s digital era, data security is a core concern for enterprises, prompting the question of how to effectively manage and protect data.

A recurring problem is insider misuse, such as an employee using internal accounts to extract and profit from data.

Zhihu question: “How do large‑scale operations prevent people from spying on and tampering with databases?” The following points summarize selected answers.

AppAnnie’s practice

AppAnnie separates its operations and security teams, granting them identical permissions but requiring security‑group approval for any production access. Most developers lack direct host access; only a few leaders can log in after explicit authorization.

All staff (operations & security) use personal accounts, never root. Every command is logged (including sudo) and monitored by OSSEC; sensitive actions trigger immediate email alerts to both teams, making covert actions extremely difficult.

The database host enforces strict firewall rules that cut an SSH session if traffic exceeds 100 KB, limiting the amount of data that can be exfiltrated even if a user runs

select *

.

When developers need production data, they must request the security team. Operations writes a dump script that masks sensitive fields, the script is reviewed and approved, then executed in production. Data is copied back through a temporary firewall rule.

Key takeaways from AppAnnie

Principle of least privilege: even with sudo rights, users cannot execute unauthorized commands or view sensitive data without approval.

Mutual supervision: six people (operations, security, CTO) receive real‑time command‑log alerts, ensuring no single individual can act alone.

The strict security processes increase operational overhead and slow down deployments, but the company accepts this trade‑off for safety.

Additional insights from other Zhihu contributors

Separation of duties: only the production support team can access production systems, and each access requires high‑level review and is limited to specific machines and accounts.

Least‑privilege access: temporary, random passwords are issued for each session.

Core machines are isolated from the internet and often require multiple keys for access.

Risk‑control teams conduct periodic audits of system permissions and security configurations.

Historical incidents (e.g., large‑scale data leaks at major tech firms) illustrate the consequences of inadequate controls.

Further observations

Complex database schemas without proper data dictionaries make it hard for developers to understand business data, and insiders who can read or modify code (developers or DBAs) are the most common threat vectors.

Operations perspective

Pre‑approval: enforce separation of duties, minimal authorization, and mandatory approval before any data access.

In‑process supervision: use network and physical isolation, key‑based login, and continuous monitoring; only designated minimal‑privilege accounts (e.g., DBA) can use root.

Post‑audit: employ audit systems and bastion hosts that record video of all sessions; dedicated audit teams regularly verify compliance with approvals and least‑privilege policies.

Comprehensive security measures (ChatGPT summary)

Least‑privilege access.

Separation of duties.

Multi‑factor authentication.

Comprehensive operation audit logs.

Encryption of sensitive data at rest.

Access control lists (ACLs) for database resources.

Real‑time monitoring and alerting.

Regular security training for staff.

Independent security team overseeing operations.

Emergency response plans for malicious activity.

Clear legal and policy frameworks with enforceable penalties.