We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A security team received an alert: a user's account was accessed from New York at 2:00 PM, then from Lagos at 2:04 PM. No human can travel 5,100 miles in four minutes. The account was compromised. The attacker had the correct password and even passed SMS-based MFA (SIM swap). But location-based controls could have caught this, flagging the impossible travel pattern and requiring step-up authentication or blocking the request outright.
Microsoft's Identity Protection system detects over 50 million impossible travel events per month across Azure AD tenants. Each one is either an account compromise or a VPN artifact. The signal alone is valuable even before you act on it.
Location is not a perfect signal. VPNs, proxies, and Tor mask real locations. IP geolocation databases are 80-90% accurate at the city level and can be wildly wrong for mobile networks. But location combined with other signals (device, time, behavior) is one of the strongest risk indicators available.
| Pattern | How It Works | Real-World Use |
|---|---|---|
| IP allowlisting | Only allow access from known IP ranges | Corporate VPN (10.0.0.0/8), office IPs |
| Geofencing | Restrict access to specific countries or regions | EU data accessible only from EU jurisdictions (GDPR) |
| Impossible travel | Detect logins from locations that are physically unreachable in the elapsed time | Microsoft Entra ID, Okta ThreatInsight |
| Network-based tiering | Different access levels for different network contexts | Full access on corporate network, read-only on public Wi-Fi |
| Compliance zones | Data residency rules restrict where data can be accessed from | HIPAA data accessible only from US endpoints |
How location is determined:
| Method | Accuracy | Spoofable? | |
|---|---|---|---|
| IP geolocation (MaxMind, IP2Location) | City-level, 80-90% | Yes (VPN, , Tor) | <1ms (local DB lookup) |
| GPS (mobile devices) | 3-5 meters | Yes (GPS spoofing apps) | 1-5 seconds |
| Wi-Fi triangulation | Building-level | Somewhat | 2-10 seconds |
| Network identity (corporate LAN) | Exact (you control the network) | Difficult (requires network access) | <1ms |
AWS restricts API calls by source IP natively. The IAM condition aws:SourceIp blocks requests from IP ranges you have not allowlisted. Every major cloud provider (GCP, Azure) supports equivalent IP-based conditions.