Segregation of Duties (SoD) in IAM
Segregation of Duties (SoD) is a fundamental security principle used in Identity and Access Management (IAM) to ensure that no single individual has the authority to execute a high-risk transaction from start to finish.
%20in%20IAM%20vlr%20training.jpg)
In simple terms, it is the concept of "splitting the keys" to a critical process. If one person holds all the keys, they have unchecked power, which creates a high risk for fraud or catastrophic error.
The Core Concept: "Toxic Combinations"
In IAM, SoD is primarily about identifying and preventing Toxic Combinations. A toxic combination occurs when a user is assigned two or more conflicting permissions (entitlements) that, when combined, allow them to bypass security controls.
The Risk Formula
If User X has Permission A (e.g., Create a Vendor) and Permission B (e.g., Pay a Vendor), they can create a fake company and pay themselves without anyone else noticing. SoD policies exist to break this link.
Real-World Examples of SoD Conflicts
Here are detailed examples across different industries showing why these duties must be separated.
1. Finance & Accounting (The Classic Example)
The Conflict: Accounts Payable vs. Payment Approval
Scenario: An employee, John, works in the finance department.
Permission 1: He has access to the "Vendor Master File" to add new bank account details.
Permission 2: He has access to the "Process Outgoing Payments" system.
The Toxic Outcome: John creates a fake vendor named "John’s Consulting," adds his personal bank account number to the profile, and then logs into the payment system to approve a $50,000 transfer to that vendor.
The SoD Fix: The person who creates the vendor must be different from the person who pays the vendor.
2. IT & Software Development (DevOps)
The Conflict: Code Development vs. Production Deployment
Scenario: Sarah is a software engineer.
Permission 1: She has "Write" access to the source code repository.
Permission 2: She has "Admin" access to the live production server.
The Toxic Outcome: Sarah accidentally writes a bug (or intentionally inserts a backdoor). Because she has production access, she bypasses the Quality Assurance (QA) team and pushes the bad code directly to the live banking app, causing a system-wide outage or security breach.
The SoD Fix: Developers write code; only Release Managers or automated pipelines (after passing tests) can deploy to production.
3. Healthcare
The Conflict: Admitting Patients vs. Billing Patients
Scenario: A hospital administrator has access to both patient intake and billing systems.
The Toxic Outcome: The administrator could create a "ghost patient" record for a person who does not exist and then bill the insurance company for expensive surgeries that never happened, pocketing the reimbursement.
The SoD Fix: The staff member who registers patients cannot be the same person who authorizes insurance claims or processes billing.
How SoD is Enforced in IAM Systems
Modern IAM tools (like SailPoint, Saviynt, or Oracle IAM) automate SoD using two main methods:
1. Preventive Controls (The Gatekeeper)
This happens during the access request.
Action: User requests access to "System B."
IAM Check: The IAM system looks at the user's current access. It sees they already have "System A."
Result: The system flags a "Toxic Combination" and automatically blocks the request or routes it to a higher-level auditor for special approval.
2. Detective Controls (The Auditor)
This happens after access has been granted (usually during quarterly audits).
Action: The IAM system scans the entire user database.
Result: It identifies that User Y has had conflicting permissions for 6 months due to a job change.
Remediation: The system flags this for the manager to "Revoke" one of the permissions immediately.
Summary Table
| Domain | Permission A (Duty 1) | Permission B (Duty 2) | Risk (Toxic Combination) |
| Finance | Create Vendor | Cut Checks/Wire Funds | Embezzlement/Fraud |
| IT | Develop Code | Move Code to Production | System outage/Backdoors |
| Security | Request Access | Approve Access | Unauthorized privileges |
| HR | Create Employee | Process Payroll | "Ghost Employee" salary theft |
IAMలో విధుల విభజన (Segregation of Duties - SoD)
సెగ్రిగేషన్ ఆఫ్ డ్యూటీస్ (SoD) అనేది ఐడెంటిటీ అండ్ యాక్సెస్ మేనేజ్మెంట్ (IAM)లో ఒక ప్రాథమిక భద్రతా సూత్రం. దీని ప్రకారం, అధిక రిస్క్ ఉండే లావాదేవీని (transaction) మొదటి నుండి చివరి వరకు పూర్తి చేసే అధికారం ఏ ఒక్క వ్యక్తికి ఉండకూడదు.
%20in%20IAM%20vlr%20training%20in%20telugu.jpg)
సాధారణ మాటల్లో చెప్పాలంటే, ఇది ఒక కీలకమైన ప్రక్రియకు సంబంధించిన "తాళాలను వేరు చేయడం" (splitting the keys) లాంటిది. ఒకవేళ అన్ని తాళాలు ఒకే వ్యక్తి దగ్గర ఉంటే, వారికి అపరిమిత అధికారం ఉంటుంది. ఇది మోసం (fraud) లేదా భారీ తప్పిదాలకు దారితీసే ప్రమాదాన్ని సృష్టిస్తుంది.
ప్రధాన ఉద్దేశం: "ప్రమాదకరమైన కలయికలు" (Toxic Combinations)
IAMలో, SoD అనేది ప్రధానంగా ప్రమాదకరమైన కలయికలను (Toxic Combinations) గుర్తించడం మరియు నివారించడం. ఒక వినియోగదారుడు రెండు లేదా అంతకంటే ఎక్కువ పరస్పర విరుద్ధమైన అనుమతులను (entitlements) కలిగి ఉన్నప్పుడు, వారు భద్రతా నియంత్రణలను దాటవేసే అవకాశం ఉంటుంది.
రిస్క్ ఫార్ములా (The Risk Formula)
ఉదాహరణకు, ఒక వినియోగదారుడు 'X'కు అనుమతి A (ఉదాహరణకు: వెండర్ను సృష్టించడం) మరియు అనుమతి B (ఉదాహరణకు: వెండర్కు డబ్బు చెల్లించడం) ఉంటే, వారు ఒక నకిలీ కంపెనీని సృష్టించి, ఎవరికీ తెలియకుండా తమకు తామే డబ్బు చెల్లించుకోవచ్చు. ఈ లింక్ను బ్రేక్ చేయడానికే SoD విధానాలు ఉన్నాయి.
SoD వైరుధ్యాలకు వాస్తవ ఉదాహరణలు
ఈ విధులను ఎందుకు వేరుగా ఉంచాలో అర్థం చేసుకోవడానికి వివిధ రంగాలకు సంబంధించిన ఉదాహరణలు ఇక్కడ ఉన్నాయి.
1. ఫైనాన్స్ & అకౌంటింగ్ (సాధారణ ఉదాహరణ)
వైరుధ్యం: అకౌంట్స్ పేయబుల్ (Accounts Payable) vs పేమెంట్ అప్రూవల్ (Payment Approval).
సందర్భం: జాన్ అనే ఉద్యోగి ఫైనాన్స్ విభాగంలో పనిచేస్తున్నాడు.
అనుమతి 1: కొత్త బ్యాంక్ ఖాతా వివరాలను జోడించడానికి అతనికి "వెండర్ మాస్టర్ ఫైల్" యాక్సెస్ ఉంది.
అనుమతి 2: అతనికి "అవుట్గోయింగ్ పేమెంట్స్" సిస్టమ్ను ప్రాసెస్ చేసే యాక్సెస్ కూడా ఉంది.
ప్రమాదకరమైన ఫలితం (Toxic Outcome): జాన్ "జాన్స్ కన్సల్టింగ్" అనే నకిలీ వెండర్ను సృష్టించి, తన వ్యక్తిగత బ్యాంక్ ఖాతా నంబర్ను దానికి జతచేస్తాడు. తర్వాత పేమెంట్ సిస్టమ్లోకి లాగిన్ అయ్యి, ఆ వెండర్కు $50,000 బదిలీని ఆమోదిస్తాడు.
SoD పరిష్కారం: వెండర్ను సృష్టించే వ్యక్తి మరియు వెండర్కు డబ్బు చెల్లించే వ్యక్తి వేర్వేరుగా ఉండాలి.
2. ఐటీ & సాఫ్ట్వేర్ డెవలప్మెంట్ (DevOps)
వైరుధ్యం: కోడ్ డెవలప్మెంట్ vs ప్రొడక్షన్ డిప్లాయ్మెంట్.
సందర్భం: సారా ఒక సాఫ్ట్వేర్ ఇంజనీర్.
అనుమతి 1: సోర్స్ కోడ్ రిపోజిటరీకి ఆమెకు "Write" యాక్సెస్ ఉంది.
అనుమతి 2: లైవ్ ప్రొడక్షన్ సర్వర్కు ఆమెకు "Admin" యాక్సెస్ ఉంది.
ప్రమాదకరమైన ఫలితం: సారా పొరపాటున ఒక బగ్ను (లేదా ఉద్దేశపూర్వకంగా ఒక బ్యాక్డోర్ను) కోడ్లో రాస్తుంది. ఆమెకు ప్రొడక్షన్ యాక్సెస్ ఉండటం వల్ల, క్వాలిటీ అస్యూరెన్స్ (QA) టీమ్ను దాటవేసి, ఆ చెడు కోడ్ను నేరుగా లైవ్ బ్యాంకింగ్ యాప్లోకి పంపిస్తుంది. దీనివల్ల సిస్టమ్ మొత్తం ఆగిపోవచ్చు లేదా భద్రతా లోపం తలెత్తవచ్చు.
SoD పరిష్కారం: డెవలపర్లు కోడ్ మాత్రమే రాయాలి; కేవలం రిలీజ్ మేనేజర్లు లేదా ఆటోమేటెడ్ పైప్లైన్లు మాత్రమే (టెస్టింగ్ పూర్తయ్యాక) ప్రొడక్షన్లోకి పంపాలి.
3. హెల్త్కేర్ (వైద్యరంగం)
వైరుధ్యం: రోగులను చేర్చుకోవడం (Admitting Patients) vs బిల్లింగ్ చేయడం (Billing Patients).
సందర్భం: ఆసుపత్రి అడ్మినిస్ట్రేటర్కు పేషెంట్ అడ్మిషన్ మరియు బిల్లింగ్ సిస్టమ్స్ రెండింటికీ యాక్సెస్ ఉంది.
ప్రమాదకరమైన ఫలితం: అడ్మినిస్ట్రేటర్ అసలు ఉనికిలో లేని వ్యక్తి పేరుతో ఒక "ఘోస్ట్ పేషెంట్" (ghost patient) రికార్డును సృష్టించి, ఎప్పుడూ జరగని ఖరీదైన ఆపరేషన్లకు ఇన్సూరెన్స్ కంపెనీకి బిల్లు పంపి, ఆ డబ్బును కాజేయవచ్చు.
SoD పరిష్కారం: రోగులను నమోదు చేసే సిబ్బంది మరియు ఇన్సూరెన్స్ క్లెయిమ్స్ లేదా బిల్లింగ్ను ప్రాసెస్ చేసే సిబ్బంది ఒకరే కాకూడదు.
IAM సిస్టమ్స్లో SoDని ఎలా అమలు చేస్తారు?
ఆధునిక IAM టూల్స్ (SailPoint, Saviynt లేదా Oracle IAM వంటివి) రెండు ప్రధాన పద్ధతులను ఉపయోగించి SoDని ఆటోమేట్ చేస్తాయి:
1. నివారణ నియంత్రణలు (Preventive Controls - గేట్కీపర్)
ఇది యాక్సెస్ రిక్వెస్ట్ సమయంలో జరుగుతుంది.
చర్య: వినియోగదారుడు "సిస్టమ్ B" కోసం యాక్సెస్ అడుగుతాడు.
IAM తనిఖీ: IAM సిస్టమ్ వినియోగదారుడి ప్రస్తుత యాక్సెస్ను చూస్తుంది. వారికి అప్పటికే "సిస్టమ్ A" ఉందని గమనిస్తుంది.
ఫలితం: సిస్టమ్ దీనిని "ప్రమాదకరమైన కలయిక"గా గుర్తించి, ఆటోమేటిక్గా రిక్వెస్ట్ను బ్లాక్ (Block) చేస్తుంది లేదా ప్రత్యేక ఆమోదం కోసం ఉన్నతాధికారికి (Auditor) పంపిస్తుంది.
2. డిటెక్టివ్ నియంత్రణలు (Detective Controls - ఆడిటర్)
ఇది యాక్సెస్ ఇచ్చిన తర్వాత (సాధారణంగా త్రైమాసిక ఆడిట్ల సమయంలో) జరుగుతుంది.
చర్య: IAM సిస్టమ్ మొత్తం యూజర్ డేటాబేస్ను స్కాన్ చేస్తుంది.
ఫలితం: ఉద్యోగ బాధ్యతలు మారడం వల్ల 'యూజర్ Y' గత 6 నెలలుగా విరుద్ధమైన అనుమతులను కలిగి ఉన్నారని ఇది గుర్తిస్తుంది.
పరిష్కారం: ఆ పర్మిషన్లలో ఒకదాన్ని వెంటనే "రద్దు" (Revoke) చేయమని మేనేజర్కు సిస్టమ్ సూచిస్తుంది.
సారాంశ పట్టిక (Summary Table)
| రంగం (Domain) | అనుమతి A (విధి 1) | అనుమతి B (విధి 2) | రిస్క్ (ప్రమాదకరమైన కలయిక) |
| ఫైనాన్స్ | వెండర్ను సృష్టించడం | చెక్కులు ఇవ్వడం/డబ్బు పంపడం | నిధుల దుర్వినియోగం/మోసం |
| ఐటీ (IT) | కోడ్ డెవలప్ చేయడం | ప్రొడక్షన్లోకి కోడ్ పంపడం | సిస్టమ్ ఆగిపోవడం/బ్యాక్డోర్స్ |
| సెక్యూరిటీ | యాక్సెస్ అభ్యర్థించడం | యాక్సెస్ ఆమోదించడం | అనధికారిక హక్కులు పొందడం |
| హెచ్ఆర్ (HR) | ఉద్యోగిని సృష్టించడం | పేరోల్ (జీతాలు) ప్రాసెస్ చేయడం | "ఘోస్ట్ ఎంప్లాయీ" ద్వారా జీతం దొంగతనం |
No comments:
Post a Comment
Note: only a member of this blog may post a comment.