Identity Based Firewall
An identity based firewall filters network traffic by user identity instead of static IP addresses. Teams set it up by linking their firewall rules to an external identity provider. In the past, network teams wrote rules using source IP addresses and ports. That approach breaks down when staff work from home or use cloud servers. Modern teams map people and service accounts to specific groups in their directory. They then write firewall policies that allow or block those groups. Still, problems
Blockchain-Based Identity + Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An identity based firewall filters network traffic by user identity instead of static IP addresses. Teams set it up by linking their firewall rules to an external identity provider.
In the past, network teams wrote rules using source IP addresses and ports. That approach breaks down when staff work from home or use cloud servers. Modern teams map people and service accounts to specific groups in their directory. They then write firewall policies that allow or block those groups. Still, problems arise when those group roles grant broad network reach. Once a user passes the check, the firewall opens the entire port.
How an identity based firewall works in practice
A traditional firewall only looks at network packets, IP headers, and port numbers. It does not know which person sits behind a laptop or server. An identity based firewall adds user context to this network check. First, a person logs in through a directory or single sign-on tool. The firewall reads that login event and links the user to their current IP. Next, the firewall checks its rule table for that user and their group.
If the group has permission to reach a database server, the traffic flows through. If the user belongs to a different team, the firewall drops the packets. The same concept applies to machine workloads in cloud networks. Cloud platforms assign service roles or tags to virtual machines and containers. The firewall checks those workload tags before it lets one service talk to another. When a person logs out, the firewall clears the link to that IP address.
What native network identity rules solve and what they miss
Linking identity to network rules solves major headaches for security and operations teams. Engineers no longer need to update IP allowlists when IP addresses change. Remote staff can reach internal systems without sharing one giant network segment. Audits also get easier because network logs show user names next to IP addresses. Security teams can revoke a user role in the directory to cut off traffic.
Yet this setup leaves a major gap inside the session itself. An identity based firewall only decides who can open a network port. Once the port is open, the firewall stops checking what the user does. A developer with database port access can still run a query that drops tables. They can also pull thousands of customer emails, phone numbers, or card numbers. The network rule sees valid packets on an allowed port and lets them pass.
Blockchain-Based Identity + Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network logs also miss the exact commands or queries run inside encrypted traffic. If an attacker steals an active laptop session, they inherit every open port. Teams often create dozens of narrow groups to limit this risk. Soon, managing hundreds of firewall groups becomes a daily burden for the team.
How to plan your identity rule groups
Start by listing the core servers and databases your teams use every day. Group your staff by the specific job they do, not by broad department names. Give each group access only to the specific ports their daily tools require. Review your directory groups every month to remove old accounts and unused permissions. Keep production database rules separate from staging and test network rules. Combine your network rules with controls that inspect actual commands and mask sensitive fields.
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
How is an identity based firewall different from a standard firewall?
A standard firewall permits or blocks traffic using IP addresses and ports. An identity based firewall checks which user or workload sent the traffic first.
Does an identity based firewall inspect database queries or shell commands?
No, it operates at the network level to open or close port traffic. It does not read, block, or mask specific SQL statements or terminal commands.
What happens when a user changes their IP address?
The user logs in again through the identity provider from their new location. The firewall updates its table and links the user rules to the new IP.