Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Soa security2
Semelhante a Soa security2 (20)
Mais de wardell henley
Mais de wardell henley (20)
Último
Último (20)
Soa security2
- 1. ® IBM Software Group © 2004 IBM Corporation Integrated Security Architecture James Andoniadis IBM Canada
- 2. IBM Software Group | Tivoli software CEO View: Increased Collaboration Brings Rewards
- 3. IBM Software Group | Tivoli software Layers of security Perimeter Defense Keep out unwanted with • Firewalls • Anti-Virus • Intrusion Detection, etc.Perimeter Defense Control Layer Assurance Layer Control Layer • Which users can come in? • What can users see and do? • Are user preferences supported? • Can user privacy be protected? Assurance Layer • Can I comply with regulations? • Can I deliver audit reports? • Am I at risk? • Can I respond to security events?
- 4. IBM Software Group | Tivoli software Pre SOA Security: Enforcement & Decision Points Access Enforcement Functionality (AEF) Access Decision Functionality (ADF)
- 5. IBM Software Group | Tivoli software Directory Management View Web Access Control Network Access Control Customer Employee Transactional Web Presentation Informational Web Presentation Certificate Status Responder External Directory Transactional Web Integration External SMTP Gateway Internal SMTP Gateway Network Dispatcher Delegated User Management Internal ePortal, LDAP- enabled apps Single Sign On Application Access Control Network Authentication & Authorization Internal Directory LOB Applications Databases Application Directory Network Operating Systems Identity Management Certifcate Authority Web Single Sign On Messaging CRM/ ERP (PeopleSoft) Meta-Directory LDAP Directory Proxy External ePortal
- 6. IBM Software Group | Tivoli software Identity and Access Management Portfolio Apps/Email UNIX/Linux NOS Databases & Applications MF/Midrange Identity Stores HRCRM, Partners Security Mgmt Objects ITIM: Provisioning • Policies • Workflow • Password Self-service • Audit trails W eb Applications Enterprise Directory •Personal Info •Credentials •Entitlements ITFIM: Federated Identity Web Services Security Portal Presentation Personalization ITAM: Web Access Management SSO, Authentication, Authorization ITDI Directory Integration ITDS Directory Server TAM for ESSO
- 7. IBM Software Group | Tivoli software
- 8. IBM Software Group | Tivoli software Governments as Identity Providers “TRUST provides ACCESS” The United States is an “Identity Provider” because it issues a Passport as proof of identification USA Vouches for its Citizens Users Users Germany:Identity Provider Users USA:Identity Provider China:Identity Provider
- 9. IBM Software Group | Tivoli software Roles: Identity Provider and Service Provider 1. Issues Network / Login credentials 2. Handles User Administration/ ID Mgmt 3. Authenticates User 4. “Vouches” for the user’s identity Service Provider controls access to services Third-party user has access to services for the duration of the federation Only manages user attributes relevant to SP Identity Provider “Vouching” party in transaction “Validation” party in transaction Service Provider Mutual TRUST
- 10. IBM Software Group | Tivoli software Federated Identity Standards
- 11. IBM Software Group | Tivoli software Agenda Enterprise Security Architecture – MASS Intro Identity, Access, and Federated Identity Management SOA Security
- 12. IBM Software Group | Tivoli software Custom Application Packaged Application Packaged Application Custom Application consumers business processes process choreography services atomic and composite ServiceConsumerServiceProvider 11 22 33 44 55 OO ApplicationCustom ApplicationOutlook SAP Custom Application business processes process choreography Services (Definitions) atomic and composite Service components ServiceConsumerServiceProvider 11 22 33 44 55 OO ApplicationISV Custom Apps Platform Operational systems Supporting Middleware MQ DB2Unix OS/390 SOA Security Encompass all Aspects of Security SOA Security Identity Authentication Authorization Confidentiality, Integrity Availability Auditing & Compliance Administration and Policy Management SCA Portlet WSRP B2B Other
- 13. IBM Software Group | Tivoli software Message-based Security : End-to-End Security Message-based security does not rely on secure transport message itself is encrypted message privacy message itself is signed message integrity message contains user identity proof of origin HTTPS HTTPS SOAP Message Connection Integrity/Privacy Connection Integrity/Privacy ?
- 14. IBM Software Group | Tivoli software Web Service Security Specifications Roadmap WSS – SOAP SecurityWSS – SOAP Security SecuritySecurity PolicyPolicy SecureSecure ConversationConversation TrustTrust FederationFederation PrivacyPrivacy AuthorizationAuthorization SOAP MessagingSOAP Messaging
- 15. IBM Software Group | Tivoli software SOAP Message Security: Extensions to Header SOAP Header allows for extensions OASIS standard “WS-Security: SOAP Message Security” defines XML for Tokens, Signatures and Encryption defines how these elements are included in SOAP Header Envelope Body Header <application data> Security Element Security Token Signature Encrypted Data Security Element
- 16. IBM Software Group | Tivoli software Security Drill Down Transport Layer Security SSL/TLS Termination 1st Layer Message Security Signature Validation/ Origin Authentication Message Level Decryption 2nd Layer Message Security Requestor Identification & Authentication & Mapping Element Level Decryption Application Security (Authorization with ESB asserted identifier) Security Policy Security Token Service Key Store, Management Authorization Nth Layer Message Security Requestor Identification & Authentication & Mapping Message Level Encryption
- 17. IBM Software Group | Tivoli software SOAP Moving to SOA – Accommodate Web Services HTTP
- 18. IBM Software Group | Tivoli software SOAP Moving to SOA – Accommodate Web Services Transport Layer Confidentiality Integrity Transport Layer Confidentiality Integrity HTTP User Interaction Based I&A Enforcement Identification & Authentication Decisions Token Based Authentication Enforcement Identity Mapping Message Layer Confidentiality Integrity
- 19. IBM Software Group | Tivoli software Moving to SOA, Adding the ESB… (Mandatory Scary Picture) Common Auditing & Reporting Service Tivoli Federated Identity Manager Tivoli Access Manager H/W: DataPower XS40 S/W: WebSphere Web Svs. G/W S/W: Tivoli Access Manager Reverse Proxy/Web PI TivoliDirectoryServer WebSphere Enterprise Service Bus DP XI50 TFIM,TAM TFIM TFIM TFIM TAMTAM
- 20. IBM Software Group | Tivoli software Further Reading On Demand Operating Environment: Security Considerations in an Extended Enterprise http://publib-b.boulder.ibm.com/abstracts/redp3928.html?Open Web Services Security Standards, Tutorials, Papers http://www.ibm.com/developerworks/views/webservices/standards.jsp http://www.ibm.com/developerworks/views/webservices/tutorials.jsp http://webservices.xml.com/ Websphere Security Fundamentals / WAS 6.0 Security Handbook http://www.redbooks.ibm.com/redpieces/abstracts/redp3944.html?Open http://www.redbooks.ibm.com/redpieces/abstracts/sg246316.html?Open IBM Tivoli Product Home Page http://www.ibm.com/software/tivoli/solutions/security/
- 21. IBM Software Group | Tivoli software Summary End-to-end Security Integration is complex Web Services and SOA security are emerging areas Moving from session level security to message level security Identity Management incorporates several security services, but other security services need to be integrated as well Audit and Event Management, Compliance and Assurance Etc. Security technology is part – process, policy, people are the others and often harder to change Only Constant is Change, but evolve around the fundamentals Establish separation of application and security management Use of open standards will help with integration of past and future technologies
- 22. IBM Software Group | Tivoli software Questions?
- 23. IBM Software Group | Tivoli software Security 101 Definitions Authentication - Identify who you are Userid/password, PKI certificates, Kerberos, Tokens, Biometrics Authorization – What you can access Access Enforcement Function / Access Decision Function Roles, Groups, Entitlements Administration – Applying security policy to resource protection Directories, administration interfaces, delegation, self-service Audit – Logging security success / failures Basis of monitoring, accountability/non-repudiation, investigation, forensics Assurance – Security integrity and compliance to policy Monitoring (Intrusion Detection, AntiVirus, Compliance), Vulnerability Testing Asset Protection Data Confidentiality, Integrity, Data Privacy Availability Backup/recovery, disaster recovery, high availability/redundance
- 24. IBM Software Group | Tivoli software Agenda Enterprise Security Architecture – MASS Intro Identity, Access, and Federated Identity Management SOA Security
- 25. IBM Software Group | Tivoli software MASS – Processes for a Security Management Architecture
- 26. IBM Software Group | Tivoli software Access Control Subsystem Purpose: Enforce security policies by gating access to, and execution of, processes and services within a computing solution via identification, authentication, and authorization processes, along with security mechanisms that use credentials and attributes. Functions: Access control monitoring and enforcement: Policy Enforcement Point/Policy Decision Point/ Policy Administration Point Identification and authentication mechanisms, including verification of secrets, cryptography (encryption and signing), and single-use versus multiple-use authentication mechanisms Authorization mechanisms, to include attributes, privileges, and permissions Enforcement mechanisms, including failure handling, bypass prevention, banners, timing and timeout, event capture, and decision and logging components Sample Technologies: RACF, platform/application security, web access control
- 27. IBM Software Group | Tivoli software Identity and Credential Subsystem Purpose: Generate, distribute, and manage the data objects that convey identity and permissions across networks and among the platforms, the processes, and the security subsystems within a computing solution. Functions: Single-use versus multiple-use mechanisms, either cryptographic or non- cryptographic Generation and verification of secrets Identities and credentials to be used in access control: identification, authentication, and access control for the purpose of user-subject binding Credentials to be used for purposes of identity in legally binding transactions Timing and duration of identification and authentication Lifecycle of credentials Anonymity and pseudonymity mechanisms Sample Technologies: Tokens (PKI, Kerberos, SAML), User registries (LDAP,AD,RACF,…), Administration consoles, Session management
- 28. IBM Software Group | Tivoli software Information Flow Control Subsystem Purpose: Enforce security policies by gating the flow of information within a computing solution, affecting the visibility of information within a computing solution, and ensuring the integrity of information flowing within a computing solution. Functions: Flow permission or prevention Flow monitoring and enforcement Transfer services and environments: open or trusted channel, open or trusted path, media conversions, manual transfer, and import to or export between domain Encryption Storage mechanisms: cryptography and hardware security modules Sample Technologies: Firewalls, VPNs, SSL
- 29. IBM Software Group | Tivoli software Security Audit Subsystem Purpose: Provide proof of compliance to the security policy. Functions: Collection of security audit data, including capture of the appropriate data, trusted transfer of audit data, and synchronization of chronologies Protection of security audit data, including use of time stamps, signing events, and storage integrity to prevent loss of data Analysis of security audit data, including review, anomaly detection, violation analysis, and attack analysis using simple heuristics or complex heuristics Alarms for loss thresholds, warning conditions, and critical events Sample Technologies: syslog, application/platform access logs
- 30. IBM Software Group | Tivoli software Solution Integrity Subsystem Purpose: address the requirement for reliable and correct operation of a computing solution in support of meeting the legal and technical standard for its processes Functions: Physical protection for data objects, such as cryptographic keys, and physical components, such as cabling, hardware, and so on Continued operations including fault tolerance, failure recovery, and self-testing Storage mechanisms: cryptography and hardware security modules Accurate time source for time measurement and time stamps Alarms and actions when physical or passive attack is detected Sample Technologies: Systems Management solutions - performance, availability, disaster recovery, storage management Operational Security tools: , Host and Network Intrusion Detection Sensors (Snort), Event Correlation tools, Host security monitoring/enforcement tools (Tripwire, TAMOS), Host/Network Vulnerability Monitors/Scanners (Neesus), Anti-Virus software
- 31. IBM Software Group | Tivoli software On Demand SolutionsOn Demand Solutions On Demand Infrastructure – Services and Components Network Security Solutions (VPNs, firewalls, intrusion detection systems) On Demand Infrastructure – OS, application, network component logging and security events logging; event management; archiving; business continuity Policy Management (authorization, privacy, federation, etc.) Identity Management Key Management Intrusion Defense Anti-Virus Management Audit & Non- Repudiation AssuranceAuthorizationIdentity Federation Credential Exchange Secure Networks and Operating Systems SecureLogging TrustModel Bindings Security and Secure Conversation (transport, protocol, message security) Security Policy Expression Privacy Policy Virtual Org Policies Mapping Rules Service/End- point Policy On Demand Security InfrastructureOn Demand Security Infrastructure On Demand Security Architecture (Logical)
Notas do Editor
- With current enterprise practices: High cost to operating the Control Layer Poor security from ineffective control layer High systems development costs
- The Security Enforcement Service (SES) is the “services” view of the commonly used “Policy Enforcement Point”/”Access Enforcement Functionality” (PEP, AEF) defined by ISO. This service is responsible for enforcing the decisions made by the SDS and thus allowing/disallowing access to resources based on these decisions. The Security Decision Service (SDS) is the “services” view of the commonly used “Policy Decision Point”/”Access Decision Functionality” (PDP, ADF) defined by ISO. This service is responsible for making the access control decisions based on information provided by the SES. Typically these decisions are of the form “can user X access resource Y in manner Z”, which translates to examples such as “Can Joe Read File A?”. These decisions may be richer than described, including information such sa time of day, requestor’s IP address, or even the contents of the request (“Transfer $10,000 from an account with a balance of $200 INTO an account with a balance of $50).
- Reality: IDC estimates that the average enterprise has 150+ directories Every application uses a directory, all are disparate, but have dependancies A SINGLE Enterprise LDAP directory is not a reality: Each application has its own varying degrees of proprietary/openess – externalization of attribues, sharing, etc. Dependancies among directories: employee/partner/customer information, passwords Authoritative sources – user profile is made up from various sources – HR, email, business apps Multiple organizations manage Varying levels of security requirements Desired Environment: A balanced federated directory model, managed under a common set of processes, tools and organizational governance Consolidate where possible, understand what directories and uses of directories, manage at appropriate level
- Need an example that describes the “multiple Identity Issues” Imagine a world where every country issues Passports for every person visiting that country. That would be chaotic. Countries would end up administering passports for non-authoritative users.
- Within a federation, organizations play one or both of two roles: identity provider and/or service provider. Identity Provider: The identity provider (IdP) is the authoritative site responsible for authenticating an end user and asserting an identity for that user in a trusted fashion to trusted partners. The identity provider is responsible for account creation, provisioning, password management, and general account management and also acts as a collection point or client to trusted identity providers. . Service Provider: Those partners who offer services but do not act as identity providers are known as service providers. The service provider (SP) relies on the IdP to assert information about a user, leaving the SP to manage only those user attributes that are relevant to the SP. Looking back at our earlier example of IBM and Hewitt: IBM would be the identity provider, they are asserting the identity of an IBM employee to Hewitt Hewitt would be the service provider. There service is the savings plan/401k management
- Managing the SOA Security includes: Identity Services Authentication Services Consistent authorization across the infrastructure components (policy managed based on a single decision point implementing authorization across layers) Auditing & Compliance to security policy Trust/Map identities between various security sub-systems Confidentiality, Integrity and Availability Administration and Policy Management
- The lock on the SOAP Message is meant to imply that the SOAP message is inherently secure in and of itself. The SOAP message can be transported in any way and its security is not affected. The SOAP message could be sent as an e-mail attachment, carried on a floppy-disk, etc, and the properties of privacy, integrity, proof of origin are not affected. In contrast, the security of a message that relies on transport security is exposed when that transport security has “gaps” – as would occur when multiple SSL hops are required to move the message from the origin to the ultimate receiver. The gaps in the transport security may or may not be an issue – depending on the trust assigned to the nodes that provide the transport compared to the trust required for the message.
- The full title of the SOAP message security specification is “Web Services Security: SOAP Message Security 1.0”, and it can be found at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf This standard defines a set of SOAP extensions that provide the ability to: send security tokens as part of a message, include an XML Digital Signature as part of a message, encrypt all or part of the message using XML Encryption These elements can be used to achieve “message-based security” for a SOAP message. That is, the message in and of itself is tamper-proof and confidental. The origin of the message is provided by the Token Element. Any change to the message will cause the signature validation to fail so content integrity is provided. An observer of the message cannot read it if it is encrypted, providing message privacy. The Oasis page for Web Service Security in general is http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
- NOTES: TRANSPORT LAYER/EDGE SECURITY This is an “optional” component. There will be pressure to use XML FW/GW as the transport layer edge termination (among other things, they do have slick acceleration capabilities). However, many customers will already have an edge termination component and won’t willingly give it up XML FW/GW (aka DataPower) While this can do message layer functionality, it typically won’t be able to handle any element level decryption (not allowed to, as opposed to not capable of). The component will typically “authenticate” based on the certificate that is included with the request and used as part of signature validation. This may well not represent the actual requestor (think sales clerk placing order versus outbound SOAP gateway at sales clerk’s company) ESB Additional tokens for identification and authentication can be handled within ESB (need as part of routing a message, user is gold/silver, for example, in addition to security type decisions, silver not authorized to request upgrades online) APPLICATION Receives requestor’s identity from ESB (eg asserted over TAI in a WAS environment) and uses this for local, application based authorization decisions Note that XML FW/GW, ESB will communicate with security services using WS-Trust, in the guise of token functionality (token validation mainly, but also the ability to extract an identity and map it appropriately for use by component) Application may use WS-Trust but this is a lot less likely (cause it means that App is getting a web services request and knows how to deal with it) but will often, through things like JACC providers, access third-party/external security services. Security services can provide all sorts of functionality. This is a “grab bag” box, to indicate that we typically want a consolidated provider/container for security policy, token functionality, key management, authorization, etc.
- MASS – Method for Architecting Secure Solutions Based on Common Criteria requirements, terminology, a methodology for enumeration of security services applied to a given system architecture