Entraid Logs
You read and export entraid logs by routing directory events to an external storage account. This setup records every user sign-in and role change across your cloud tenant. Most security teams start by granting broad reader roles to central log tools. Broad roles create risk because too many staff members can read sensitive identity records. Overly wide permissions also fail to limit what users do after they log in. How entraid logs work in your cloud tenant The cloud directory creates three
Kubernetes Audit Logs: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You read and export entraid logs by routing directory events to an external storage account. This setup records every user sign-in and role change across your cloud tenant. Most security teams start by granting broad reader roles to central log tools. Broad roles create risk because too many staff members can read sensitive identity records. Overly wide permissions also fail to limit what users do after they log in.
How entraid logs work in your cloud tenant
The cloud directory creates three main event streams for your security team. Sign-in events track when a person or service tries to log in. Audit events record changes to users, groups, apps, and directory roles. Provisioning events show when the directory creates or updates accounts in other external systems.
Admins set up diagnostic rules to send these records to a central workspace. You can also send the event stream to long-term storage or an event hub. Security teams must hold a specific reader role to view these directory records. Without export rules, the cloud directory only keeps your event history for a short window.
When a user logs in, the directory checks their rules and device status. It then writes an entry with the user name, app name, and IP address. If an admin changes a group, the audit stream records who made the change. This flow gives teams a clear history of who entered the cloud tenant.
What directory events solve and the gap they leave
Directory logs are great for tracking who enters your network and when. They help your team spot failed sign-in attempts from strange locations right away. They also prove when an admin added a user to a high-level role. This history is vital when you investigate a stolen password or bad account change.
Still, directory events only see the front door of your tech stack. Once a user logs in to a database or server, directory tracking stops. The identity log shows that an engineer opened a database tool this morning. It does not show which tables they read or which rows they deleted.
Shared database accounts make this visibility gap much worse for security teams. Many engineers log in through the directory and then use one shared database password. The database only sees the shared account name, not the real cloud user. Your team cannot link a bad query back to a single person.
Kubernetes Audit Logs: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Directory logs also cannot stop a risky command while it runs in flight. They record the sign-in event after the check finishes, then step out of the way. If an engineer runs a query that pulls card numbers, the directory knows nothing. You need controls that inspect commands and mask emails or phone numbers in results.
How to tighten log rules and session checks
Start by removing broad admin roles from people who only read event records. Assign the smallest reader role needed to view security events in your workspace. Separate the team that manages user roles from the team that checks audit trails. This split prevents an admin from hiding their own bad changes in the directory.
Next, send your sign-in and audit streams to an immutable storage bucket. Set a clear retention rule so records stay safe for your yearly security checks. Alert your team when anyone changes a diagnostic rule or turns off log export. Attackers often try to stop event streams right after they steal an admin account.
Finally, pair your identity records with query-level logs for every database and server. Make sure every command links directly to the directory identity of the real user. Apply data masking rules so queries rewrite card numbers and national IDs in results. This step closes the gap between the front door and the actual data layer.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What are the main types of entraid logs?
The three main types are sign-in logs, audit logs, and provisioning logs. Sign-in logs track user logins, while audit logs track changes to roles and apps. Provisioning logs record account updates sent to external apps and cloud services.
Do entraid logs show database queries or server commands?
No, directory logs only record the initial login and changes to cloud roles. They do not record SQL queries, shell commands, or API calls inside your systems. You need runtime session controls to capture and check actions inside databases and servers.
How can teams protect entraid logs from tampering?
Teams stream directory events to a separate storage account with strict audit storage rules. They also limit who holds security reader roles and alert on diagnostic setting changes. This setup stops admins from deleting records after making unauthorized role updates.