41
IGI Architecture ASPECTS/CONSIDERATIONS OF IGI DESIGN David Edwards Tech Enablement SME – IBM Security Identity Products
IGI ArchitectureASPECTS/CONSIDERATIONS OF IGI DESIGN
David EdwardsTech Enablement SME – IBM Security Identity Products
3 IBM Security
Aim of this module:Explore the IGI product architecture and deployment patterns for solution design
4 IBM Security
Agenda
• Architectural Overview
• Design Considerations
• Adapters and Connectors for Integration
• High Availability and Disaster Recovery
• Deployment (Architectural) Patterns Non-Production systems like
• “Single-server Read-only” - Sandbox / Governance-only• “PoC/Pilot with Integration” – Pilot / PoC
Production• “Simple production” pattern – all on VA with HA• “Normal production” pattern – VA, remote DB all with HA
5 IBM Security
Module Outcomes
At the end of this module you should understand:
• IGI high-level architecture
• Architectural considerations
• Data Integration
• High Availability and Disaster Recovery options
• Common deployment patterns
01 02 03Architectural Overview Component View ISIM etc. Integration
Architectural OverviewA LOOK AT…
9 IBM Security
Architectural Overview
• IGI is a Java application running in a Virtual Appliance
• Three licensing components: Analytics, Compliance and Lifecycle
• Two main UIs; Admin Console for administrators and the Service Center for business users
• Uses RDBMS, either onboard (Postgres) or remote (DB2, Oracle) at data store
• Integration with target systems directly, and via the Identity Broker (agent-based or via SDI onboard or on remote server)
• Other integrations include use of mail notifications, SAP GRC AC for risk evaluation, ticketing systems, external apps and the IBM Security Access Request mobile app
IGI Application
Broker Application
Service Center
APIs (Java, REST)
Admin Console
IGI DB SDI(s) In
tegr
atio
n Se
rver
*
SDI(s)
Business usersAdministrators
Systems, Applications, Datastores, HR Systems (on-prem and cloud)
Dat
a Se
rver
Apps ISAR
IGI DB
MailServer
VA L
MI/C
LIIG
I Virt
ual A
pplia
nce
SAP GRC AC
Ext.Risk Eval.
Files/ Reports
Ticketing System
Ext.W/F
Analytics
Compliance Lifecycle
10 IBM Security
Architectural Overview – Network & Security Protocols
IGI Application
Broker Application
Bulkload / Reporting Enterprise Connectors
Service Center
APIs (Java, REST)
Admin Console
IGI DB SDI(s) In
tegr
atio
n Se
rver
*
SDI(s)
Business usersAdministrators
Systems, Applications, Datastores, HR Systems (on-prem and cloud)
Dat
a Se
rver
Apps ISAR
IGI DB
MailServer
VA L
MI/C
LIIG
I Virt
ual A
pplia
nce
SAP GRC AC
Ext.Risk Eval.
Files/ Reports
Ticketing System
Ext.W/F
• UIs/APIs HTTPS Use of OIDC for Auth’n
• IGI Target Integration Bulkload is direct upload from
local system (browser system) Enterprise Connectors support
various protocols Broker -> Agent us old ADK
(aka DAML/DSML v2) over SSL
Broker -> SDI use RMI / SSL SDI to target support various
protocols
• Other Communication IGI DB – JDBC over SSL Mail server – SMTP over SSL Others use https
https
https
https https https https
SMTP/SSL
JDBC /SSL
rmi/SSL
OIDC
Var.Var.
ADK/SSL
Var.local
Analytics
Compliance Lifecycle
11 IBM Security
Architectural Overview – Components and Major Functions
IGI Application
Broker Application
Bulkload / Reporting Enterprise Connectors
Access Governance Core
Process DesignerTask Planner Report
Designer
ARC for SAP
Access Risk Controls
Access Optimizer
Service Center
APIs (Java, REST)
Admin Console
Authorization ManagerRule Engine Workflow
Engine
IGI DB SDI(s) In
tegr
atio
n Se
rver
*
SDI(s)
Business usersAdministrators
Systems, Applications, Datastores, HR Systems (on-prem and cloud)
Dat
a Se
rver
Apps ISAR
IGI DB
MailServer
VA L
MI/C
LIIG
I Virt
ual A
pplia
nce
SAP GRC AC
Ext.Risk Eval.
Files/ Reports
Ticketing System
Ext.W/F
• UIs/APIs Admin Console & Service Center APIs (Java and REST) VA Local Management Interface
and Command Line Interface
• IGI Modules “Compliance” ~= Access Risk
Controls & Access Risk Controls for SAP (ARCS)
“Analytics” ~= Access Optimizer Core & “Lifecycle” ~= Access
Governance Core Common modules ~= Task
Planner, Process Designer and Report Designer
Also, Enterprise Connectors
• Other Major Functions Rule Engine (Event Processing) Authorization Manager
(Entitlement Server) Workflow Engine Bulkload and Reporting
12 IBM Security
Architectural Overview – With other IBM Identity Products
IGI Application
Broker Application
ISIM
ISIM Application
ISIM LDAP
Bulkload / Reporting Enterprise Connectors
Access Governance Core
Process DesignerTask Planner Report
Designer
ARC for SAP
Access Risk Controls
Access Optimizer
Service Center
APIs (Java, REST)
Admin Console
Authorization ManagerRule Engine Workflow
Engine
IGI DB SDI(s) In
tegr
atio
n Se
rver
*
SDI(s)
Business usersAdministrators
Systems, Applications, Datastores, HR Systems (on-prem and cloud)
Dat
a Se
rver
Apps ISAR
IGI DB
MailServer
VA L
MI/C
LIIG
I Virt
ual A
pplia
nce
SAP GRC AC
Ext.Risk Eval.
SDI(s)
Systems, Apps, etc.
ISIM DB
Files/ Reports
ISIQ (docker)
ISIGADI** (SDI)
Cloud Identity Analyze
CIA Bridge (docker)
Cloud Identity Govern
ISIQ (docker)
Ticketing System
Ext.W/F
01 02 03Why do projects fail? Governance of what? System integration?
Design/Deployment Considerations
NEED TO CONSIDER…
14 IBM Security
Common Reasons for Project Failure
• Two worlds apart: IT and Business did not engage, despite several declarations of good intentions
• Lost in translation: access data is not understood by the business
• Too ambitious: too many applications to onboard and control, lack of understanding where the crown jewels are
• Mentality did not change: still treated as a ‘User Provisioning’ Project, staff lacked the understanding of the compliance related pressure
15 IBM Security
Governance of What?
• Understanding the applications estate is key to project success Applications are above ‘targets’ (e.g. many applications rely on AD, or RACF) Each application has its own risk/business relevance, regardless of the underlying authorization
system Onboarding applications is way more than building a connector
• Risk-based prioritization of the ‘Application estate’ is the first, most important step Is this an identity management project or an identity governance project? Priority, may mean best ROI for identity management OR highest risk for identity governance
• The ‘30%’ rule: spend at least 30% of the project budget on ‘translation’ (e.g. write descriptions, group entitlements based on common tasks, etc.). Make IT entitlements readable by the business
• Reduce the ‘connector obsession’: Identity Governance does not mean only ‘automation’. For many scenarios ‘read-only + reconciliation’ is a big improvement on what the customer already
has.
16 IBM Security
Identify key stakeholders
• Identify key stakeholders and define their duties Access lifecycle management approvers SoD & mitigation controls evaluator or approvers User managers Risk managers Supervisors to certification campaigns
• Don’t forget stakeholders that do not use the Identity Governance solution directly HR CIO/CFO Legal
• Note – There is a separate module on lessons learned
17 IBM Security
Preparing for an Identity Governance deployment
The deployment team members must work with their various customer counterparts to gather the following information
• User listings and details about authoritative user resources (feeds from HR systems) Source of the user data, export files, spreadsheets, CSV, HR feeds, and communication protocols for data exchange
• User hierarchies, employee – manager relationships, and hierarchy update processes
• Integration with external identities sources Users, attributes, application permissions, accounts management
• Organizational chart
• Roles catalog Administrative roles Business roles
• Entitlements and entitlement groupings How to translate this into the IGI data model, permissions, IT Roles, Business Roles, External Roles, and Admin Roles
• Business applications Application owners Accounts on each application Target systems/applications/datastores
• Business Activity Tree And any Separation of Duties and Sensitive Access policies in use or identified
• Expected reports, that is, who can access reporting, what reports are required or expected, format and delivery method
18 IBM Security
Identify business processes around Identity Governance
Business processes impacted by the Identity Governance solution
• User creation, user termination
• User assignment to organizational units
• Role lifecycle management (Role creation, removal, and consolidation)
• Role assignments
• Access lifecycle management
• Identity reconciliations such as users, attributes, application permissions, accounts
• Segregation of Duties (SoD) and Sensitive Accesses (SA) management
• Mitigations of risks
• Periodic risk analysis
• Role delegations
• Periodic recertification
19 IBM Security
What About Integration with Other Systems?
• What data needs to be fed in or pulled out? Org structure Users/People (Employees, Contractors, Customers etc.) Target systems and applications Accounts, Permissions, acct-perm mapping Business activities, Risk definitions (like SoD),
BA mapping Other, like ticketing, email, external apps? What reports?
• Four methods to get data in/out Bulkload tools (in) & Reports (out) API (in/out) Enterprise Connectors (in/out) Identity Broker Adapters (in/out)
• Which mechanism to use for each?
• Need to consider both initial load AND ongoing synchronization
• Is there an existing ISIM deployment to be integrated?
01 02 03Adapters and connectors Some integrations Some more integrations
Common Integrations with IGIDO YOU NEED TO ALLOW FOR…
21 IBM Security
Adapters and Connectors as part of the IGI Flow
§ Important to understand the significance of the IGI Event Queueso Events are processed in real time by the
Access Governance Core (AGC) rule engine.
o The common integration point for the Enterprise Connectors and Brokerage Adapters are the Event Queues
§ Queues and internal flows will be covered in detail in a later module
§ Adapters from the ISIM heritageo Agentless (TDI-based) or agent-basedo Identity Brokerage component drives
them
§ Connectors are the legacy integration – rarely used except for:o CSV connectoro JDBC connector
§ More about the ISIM<->IGI integration in a later session.
22 IBM Security
Adapters and Connectors as part of the IGI Flow
• Different architectural patterns: Direct legacy Enterprise Connectors – no need for
the broker, but limited connectors Identity Brokerage adapters
• Agent-based (AD, SQLServer, Notes, mainframe and iOS) vs. agentless, and
• Leveraged directly from IGI – either using an on-board SDI or an SDI hosted elsewhere, or
• Running on an ISIM system and sync’d via ISIGADI or ISIQ
• Other considerations Always check the Adapter guide / release notes for
constraints; some won’t run in ISIM or IGI, some cannot run on on-board SDI
Only HA option is Connectors or on-board SDI Can have up to 10 SDIs on-board If adapter is on ISIM do account attributes need to
be sync’d with IGI and how hard is it to synch For greenfields, should aim to deploy Brokerage
Adapters with on-board SDI
AdaptersCon
nect
ors
Adapters
23 IBM Security
Common Integrations with IGI
• IGI and Secret Server Traditional provisioning adapter integration – IGI providing management/governance of Secret Server accesses
• IGI and QRadar Log shipping to QRadar for SIEM – a DSM is available for IGI (and other identity components) Integration with User Behavior Analytics
• IGI and ServiceNow Traditional provisioning adapter integration – IGI providing management/governance of SN accesses ServiceNow providing an external interface to drive management/governance activity in IGI Callout from workflow to ServiceNow for external approvals
• IGI and SAP HR Feed from SAP HR via the Brokerage Adapter Traditional provisioning adapter integration – IGI providing management/governance of SAP accesses Fine-grained read-only analysis for SAP access model (AOs, TCODES, fields/values) Call out to SAP GRC AC to perform external risk evaluation
• IGI and the mainframe Traditional provisioning adapter integration for RACF, ACF2, TopSecret (and iOS) Additional fine-grained governance on RACF data with zSecure RACF adapter
24 IBM Security
Adapter jar
IGI and Secret Server – Architecture and Integration
• Architecture
• Standard TDI/RMI adapter architecture Requires broker, TDI, various libraries installed in TDI Plus: Adapter package file, Adapter mapping file, connector jar file
• Uses HTTPs to connect to Secret Server (using REST API)
• Supports account add, mod, suspend/restore, and password – NO delete
• Reconcile consumes accounts, folders, secrets and groups
IGI
Brok
er
TDI
RM
I D
ispa
tche
r
Thyc
otic
Ad
apte
rRMI
Adapter jar Thycotic conn. jar
Secr
et
Serv
er
cert
SSer
ver
Appl
icat
ion
SSDB
HTTPS
System Login (acct) Add, Change, Suspend, Restore, Password, Reconciliation
25 IBM Security
User Behavior Analytics
IGI and QRadar – Architecture and Integration
• Architecture
• IGI DSM uses JDBC to pull events from the AUDIT_LOG table Maps them and stores them in the event store Event processing will apply any rules to determine any ”situations” (not ootb)
• UBA is a standalone Docker container connected to QRadar SIEM Both QRadar and UBA components apply logic (roles) to determine user risk and offenses May also use the Machine Learning Analytics app on QRadar to determine offenses
• Either could trigger actions back into IGI Not provided OOTB, but could use IGI REST API for functions like “suspend user”
JDBC
IGI
IGI Application
AUDIT_LOGIGI DB
QRadar
Event Store
IGI DSMEvent pull from IGI AUDIT_LOG table
User risk analysis
Dashboard
Actions back to IGI from QRadar
Security Dude
UBA Store
Rules UBA Rules
MLA
26 IBM Security
IGI
Adapter jar
IGI and ServiceNow – Architecture and Integration
• Architecture
• Flows1. ServiceNow Provisioning Adapter – normal RMI/Broker adapter run in TDI (uses REST)2. IGI Integration App – access requests/acct mgmt in ServiceNow ( “Deep Integration” )
• IGI Integration App installed in ServiceNow calls IGI via REST API• ServiceNow Sync job to update tickets generated for access requests based on completed events in IGI
3. Calling ServiceNow from IGI workflow – custom jar file called to talk to ServiceNow
IGI
Brok
er
TDI
RM
I D
ispa
tche
r
Serv
iceN
ow
Adap
terRMI
Adapter jar
ServiceNow
cert
HTTPS (REST)
IGIDBs
W/F
1
3SN sync
2IGI Integration
AppHTTPS (REST)
SN sync jar
27 IBM Security
SAP Environment (On-Premise)
SAP NetWeaver
IGI Application/Database
IGI and SAP – Architecture and Integration
• Architecture (integration details over)
Access Governance Core
Broker
TDIRMI Dispatcher
SAP HR Adapter
RMI
SAP JCo
IGI Data Warehouse
1
SAP HCM (HR) Module
SAP GRC AC & CUP Modules
Other SAP ModulesOther SAP ModulesOther SAP Modules
SAP Cloud
Other SAP ModulesOther SAP ModulesOther SAP Modules
Cust. BAPICode
SAP Provisioning Adapters (NetWeaver, HANA etc.)
Access Risk Controls
Enterprise Connectors
ARCS
2 2
3
* Legacy SAP EC’s not shown
4
HTTP
Var. Var. HTTP
sync
Risk Engine
28 IBM Security
IGI and SAP – Integration Details
1. HR Feed SAP HCM is a source of users (employees etc.)
and org structure Have an IB Adapter to pull users/OUs from SAP
HCM (“… Identity Adapter for SAP HR Feed”) Uses the Broker and IN queue Implemented as a set of TDI ALs Communicates via BAPI & RFC methods (JCo)
2. SAP Provisioning Manage users/accounts and access memberships IB Adapters:
• SAP NetWeaver – via JCo• SAP HANA Database – via JDBC• SAP AS Java (UME) – via SPML (DSML V2)• SAP Sybase – via JDBC
Currently no SAP Cloud adapters• Could use the same IB mechanism
• We won’t explore these two further (see refs)
3. SAP Fine-grained Governance Access Risk Controls for SAP (ARCS) –
specialized fine-grained SAP access analysis component
Leverages a set of BAPI modules deployed into SAP to extract access objects and relationships
Communicates via the JCo API Can be integrated with Access Risk Controls
(ARC) so SAP objects and risks are visible in ARC
4. External Risk Analysis Can replace internal risk analysis (SoD/SA) with
external Sample for SAP provided to connect to SAP
GRC Access Control to check Could also leverage IGI external authorization
and call the SAP GRC CUP (user provisioning) to transfer an in-flight access request to SAP
Requires customization
29 IBM Security
• Architecture
• Older DAML (ADK) agent-based adapters Agent is installed on the mainframe The “agent” comprises multiple components; a DAML agent (like the AD one), REXX scripts and
jobs/started tasks DAML module in the Broker communicates directly with it The “zSecure RACF” adapter has additional zSecre CARLA modules to extract more detail
• Uses DAML to connect to the agent (direct TCP/IP connection) with SSL
• Functionality depends on the adapter (see separate deck)
Mainframe
Unix Systems Services (OMVS)
Adapter jar
IGI and the Mainframe – Architecture and Integration
IGI
Brok
er DAML (TCP/IP)
Adapter jar
Agent
zOS MVS
RACF / ACF2 / TS Datastore
Programs
Tasks
01 02 03HA for the VAHA for DB and other components DR Considerations
HA and DR ConsiderationsFOR PRODUCTION…
31 IBM Security
HA for the Virtual Appliance
• VA is now the main consideration for design/deployment Has application, DB and SDI on-board Could be the only component used in simple deployments LDAP is gone (from IGI 5.2.5)
• VA supports two approaches to HA Parallel VAs behind a load balancer Use of the VA Clustering mechanism
• Parallel VAs without “VA Clustering” IGI is largely stateless – everything is stored in DB Could deploy parallel VAs behind a Load Balancer
• Constraints Need to ship configuration between instances Need to enable stickiness (“Session affinity”) between LB and
instance• May still lose some session state between instances on failure
Drives the use of external DB• Otherwise almost impossible to keep DB in synch
Might be challenging with on-board SDIs• Keeping in-synch (e.g. how to handle a failure of a large recon mid-
stream)
• See https://www.ibm.com/support/knowledgecenter/SSGHJR_5.2.5/com.ibm.igi.doc/installing/ref/r_load_balancer.html
Loadbalancers
IGI VA
IGI App.
Broker
UIs
IGI VA
IGI App.
Broker
UIs
IGI VA
IGI App.
Broker
UIs
IGI DB
IGI DB
Integration SDI may on own server, DB server or on VAs
Systems, Apps, etc.
SDI(s)
Manual config replication
Business usersAdministrators Apps ISAR
32 IBM Security
Clustering for the Virtual Appliance
• VA also has a clustering mechanism (like all IAM VAs) Have one “Primary” node, and n “Member” nodes
• One member node is called the “Secondary” and is next in line for promotion to Primary
• Primary provides the central management for all nodes in the cluster – primary node must be available to manage cluster
Clustering mechanism handles synchronization between Primary and Member nodes
Can enable Postgres replication in LMI Clustering will replicate and SDI configuration changes to
other nodes If local SDI is unavailable, will route to SDI on another node Also good for DR if you can guarantee reliable bandwidth
between primary and DR sites
• Can load balance to each cluster members Don’t have to do all, could have one for other tasks
• Ideal solution for smaller deployments where the Postgres DB can be used For larger deployments should use external DB
• Most adapters can use on-board SDI Some will need to run on an external SDI (dedicated server
or co-located with the external DB)
Loadbalancers
IGI VA
IGI App.
Broker
UIs
IGI VA
IGI App.
Broker
UIs
IGI VA
IGI App.
Broker
UIs
IGI DB
May have remote DB and SDI(s)Systems, Apps, etc.
SDI
Cluster replication
Business usersAdministrators Apps ISAR
IGI DB SD
I IGI DB SD
I
Primary Secondary Members
33 IBM Security
Availability Options for Datastore and SDI (No LDAP!)
• DB either: On-board – Postgres
• Not recommended for production• Still concerns around scalability/performance• Work ongoing
Remote – DB2 or Oracle• Recommended for production• Tuning/performance is a known• DB-provided tools for HA/DR
• IGI requires a constant/single address for DB/SDI Need mechanism to virtualize IP
• Load balancer with failover for components Or, clustering (HACMP or similar)
• Not common for IGI deployments
• Be aware, application is very “chatty” with DB Local network subnet in same building is much better
than geographically remote and/or different network
• Postgres Replication Single Postgres instance per VA Appliance clustering will handle replication Application will only use local DB not other VA There is a DB migration tool; Postgres > DB2 or Oracle
• DB2 Failover/Replication DB2 has a high rate of change Options
• DB2 HADR – hot-hot/hot-warm/hot-cold• DB2 log shipping – hot-warm/hot-cold• DB2 backup/restore – hot-warm/hot-cold
• Oracle Failover/Replication – TBA
• SDI Failover/Replication If using on-board SDI, appliance clustering will handle
failover/replication If remote SDI, there is no simple mechanism for
failover/replication - may need to build in May still get issues if a transaction is in-flight during
failure
DB2 HA Options: http://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.ha.doc/doc/c0051346.html
34 IBM Security
How About Disaster Recovery (or BCP)?
• Rarely does Identity Governance/Management need to be immediately available in a recovery Critical business apps come first, if access is needed it’s normally done locally (break-glass) Exception is usually reverse-password synch
• So probably looking at Hot-Cold model across to DR site Data replication across sites
• What is the customers’ DR infrastructure and procedures? Can you leverage that?
• Probably will need: Either a Hot-Hot model with cluster spread across primary and backup sites (depends on bandwidth), or Hot-Warm model with:
• IGI VA• Configuration snapshot export/import periodically (or tied to significant change)• See: Setting up a Secondary VA for Active-Passive Configuration,
https://www.ibm.com/support/knowledgecenter/SSGHJR_5.2.5/com.ibm.igi.doc/installing/cpt/c_planning_dr.html• Datastores – Log shipping or export/import• SDI – Configuration replication periodically (or tied to significant change)
01 02 03Single-server Read-only Pilot/POC with Integration Production Patterns
Deployment PatternsSOME SAMPLE…
36 IBM Security
IGI Application
Non-Prod Deployment Pattern – “Single-server Read-only”
• Often need a single IGI environment with no provisioning: Standalone training or demonstration environment Simple Proof-of-Concept API development environment Standalone data analysis or governance environment
• Read-only data consumption No need to push data/changes back down to target Only need data in IGI for use Data consumption via
• Bulkload for XLS files for almost all data objects• CSV Enterprise Connector for CSV files for some data objects
Would normally consume; people, applications, org structure, accounts, entitlements, entitlement mapping• May also consume risk objects; BAs, risk definitions, mitigations
Customer/business could provide the XLS/CSV data Optionally could use Brokerage and Adapters to consume data
• AD is common
• Supports Reporting
• *Limited benefit for Lifecycle use cases PoCs often need to show end-to-end use cases so this pattern is
limited
• Very small, lightweight deployment Easily replicated and shared
Broker Application
Service Center
APIs (Java, REST)
Admin Console
IGI DB SDI(s)
Business usersAdministrators Apps ISAR
IGI V
A
XLS Files CSV Files
Bulkload / Reporting Enterprise Connectors
Reports
Analytics Compliance Lifecycle*
37 IBM Security
IGI Application
Non-Prod Deployment Pattern – “PoC / Pilot With Integration”
• Often need a single IGI environment with provisioning: Standalone training or demonstration environment Simple Proof-of-Concept Production pilot (without HA/DR) API development environment
• Similar to Single-server Read-only but with provisioning integration to systems Common to integrate with Active Directory for PoCs May also want to include a HR Adapter for for user-based use
cases Use Broker and on-board SDI for adapters
• Check if adapters need an external SDI Still using the on-board Postgres DB (no need for external DB)
• Could support Analytics, Compliance and Lifecycle use cases
• Very small, lightweight deployment Easily replicated and shared
Broker Application
Service Center
APIs (Java, REST)
Admin Console
IGI DB SDI(s)
Business usersAdministrators Apps ISAR
IGI V
A
XLS Files CSV Files
Bulkload / Reporting Enterprise Connectors
Reports
Analytics Compliance Lifecycle
Systems, Apps, etc.
AD, HR etc.
38 IBM Security
Non-Prod Deployment Pattern – “PoC / Pilot With Integration”
• Use a mix of Connectors, Adapters, and Bulkload Enterprise Connectors extremely flexible and fast
to configure for non-standard HR feed and applications
Check requirements for ISIM adapters (e.g. does it require separate TDI)
Bulkload for supporting data, such as industry specific Activity Tree, Risk Definitions etc
• Demonstrates a number of key features Out of the box bidirectional reconciliation (e.g. to
Active Directory) Account matching (and handling unmatched
accounts) Flexibility to cope with customer’s own data Supplying our own content to give customer a
starting point (e.g. APQC trees and risk definitions)
• What about if ISIM is required… Need either ISIGADI or ISIQ (new)
• ISIGADI• TDI-based but should run on external TDI for greater
control• Performance considerations (might be ok for PoC)
• ISIQ• New Docker-based integration platform• Focus on performance and manageability• Preferred choice
Identity (HR) Feed• Already in ISIM and then Sync’d to IGI (via ISIGADI
or ISIQ) Target (Accounts/Permissions) Provision/Recon
• Customer likely to want to see that they can deploy new targets on IGI, avoiding adding to their ISIM deployment
Most components to deploy• Assumes the customer already has an ISIM
deployment• Otherwise – lots of moving parts and integration
points to manage• Beware of all the UIs in the solution!
39 IBM Security
Production Deployment Patterns
• Based on customer requirements and need for ootb/custom functionality May need ISIM for specific requirements, but this should be avoided unless absolutely necessary
• Production patterns will be similar to the previous PoC / Pilot Patterns Consider DB – on-board (Postgres) vs. remote (DB2 or Oracle)
• Remote is recommended for most production deployments Can you use on-board SDI instances?
• Check the docs for adapters you need to see if they must run on external SDI
• What about Availability, including High Availability (HA) Does a governance solution need HA? Really? Even for provisioning, probably don’t need HA Except maybe reverse password synch – might be other drivers for HA Will affect
• VA clustering mechanism and number of nodes• DB availability mechanism (on-board is covered by clustering, remote will need some availability mechanism)• Adapters and SDI – are they all on-board, or are some remote and if so HA implications
• What about Disaster Recovery (or BCP) Is governance/provisioning a mission critical application to be restored immediately? Probably not A Hot-Hot DR model may be appropriate for some A Hot-Warm DR model may be appropriate for most, particularly governance only
40 IBM Security
Prod Deployment Pattern – “Simple Production”
• Simplest production deployment pattern has VAs in a VA Cluster behind a Load Balancer set
• Maybe one not behind Load Balancer for specific tasks (e.g. role mining)
Use of the on-board (Postgres) DB Use of on-board SDI instances for adapters Other integrations as per the non-production (e.g. use of
bulkload, reporting, email, Ent. Conn. for CSV data) Could have ISAM/WebSEAL in front of UIs
• HA is achieved through VAs behind a load balancer with session affinity VA Cluster mechanism manages data replication for the
application configuration, database and SDI
• Key factor here is size of deployment Support not recommending for “large” deployments Currently don’t have good metrics on the scale of
deployment this is appropriate for Some 5.2.5 performance testing done on 120,000 users!
• But performance testing shows on-board Postgres is generally slower than a remote DB2
Loadbalancers
IGI VA
IGI App.
Broker
UIs
IGI VA
IGI App.
Broker
UIs
IGI VA
IGI App.
Broker
UIs
IGI DB
Systems, Apps, etc.
SDI(s
)
Cluster replication
Business usersAdministrators Apps ISAR
IGI DB SD
I(s)
IGI DB SD
I(s)
Primary Secondary Member
41 IBM Security
IntegrationIGI DB
Prod Deployment Pattern – “Normal Production”
• Normal production deployment pattern has VAs in a VA Cluster behind a Load Balancer set
• Maybe one not behind Load Balancer for specific tasks (e.g. role mining)
Use of remote DB for performance and scalability Use of on-board and remote SDI for adapters
• Preference given to on-board• Remote SDIs may be on DB server or other server
Other integrations as per the non-production (e.g. use of bulkload, reporting, email, Ent. Conn. for CSV data)
Could have ISAM/WebSEAL in front of UIs
• HA is achieved through VAs behind a load balancer with session affinity VA Cluster mechanism manages data replication for
the application configuration and on-board SDI DB would need to use it’s own replication (like HADR
for DB2) SDI HA is provided for for on-board SDIs
• Remote SDIs do not have any in-built HA, need building
• Example from support with ISAM: https://www-01.ibm.com/support/docview.wss?uid=swg27049923
Loadbalancers
IGI VA
IGI App.
Broker
UIsIGI VA
IGI App.
Broker
UIsIGI VA
IGI App.
Broker
UIs
SDI(s)
Cluster replication
Business usersAdministrators Apps ISAR
Pri Sec MbrSDI(s) SDI(s)
IGI DB
IGI DB
Integration
Systems, Apps, etc.
SDI(s)
Close
43 IBM Security
Module Summary
You should now:
• IGI high-level architecture
• Architectural considerations
• Data Integration
• High Availability and Disaster Recovery options
• Common deployment patterns
ibm.com/security
securityintelligence.com
xforce.ibmcloud.com
@ibmsecurity
youtube/user/ibmsecuritysolutions
© Copyright IBM Corporation 2016. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and / or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective.
IBM DOES NOT WARRANT THAT ANYSYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.
FOLLOW US ON:
THANK YOU
