1 / 41

Security in Grid and Grid Security Services

Security in Grid and Grid Security Services. Yuri Demchenko System and Network Engineering Group University of Amsterdam 11 March 2008, UvA, Amsterdam. Outline. Grid and specific security requirements Current Web Services based Grid security model

zwi
Télécharger la présentation

Security in Grid and Grid Security Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security in Grid and Grid Security Services Yuri Demchenko System and Network Engineering Group University of Amsterdam 11 March 2008, UvA, Amsterdam

  2. Outline • Grid and specific security requirements • Current Web Services based Grid security model • Authentication, Delegation, Trust management • Virtual Organisation as a security federation framework in Grid • VO and AuthZ in Grid • Two basic security models (TCB and OSI/Internet) and related standards • Grid security implementation in existing Grid middleware frameworks • Globus Toolkit, gLite, Unicore, Alien • Research problems in Grid Security • Grid Security model (combining TCB and OSI security models) • AuthZ and Security session/context management • Virtualisation in Grid and Security • Trusted Computing Platform Architecture (TCPA) Grid Security

  3. Grid definition and Grid types (GFD.80 and GFD-I.113) • Grid is for sharing computing resources and unique resources in the distributed heterogeneous environment by means of resource and user virtualisation • GFD.80 – Open Grid Services Architecture (OGSA) • Grid systems and applications aim to integrate, virtualize, and manage resources and services within distributed, heterogeneous, dynamic "virtual organizations" • Grid types (GFD-I.113 – Technical strategy for OGF 2007-2010) • Cluster Grids • Data Center Grids • Collaboration Grids • Grid standardisation is coordinated and supported by Open Grid Forum (OGF) and documented in OGF standards • http://www.ogf.org/ • http://www.ogf.org/gf/docs/?final Grid Security

  4. Components of the OGSA Security Architecture • Grid/OGSA security architecture is build on the Web Services Security Grid Security

  5. Zone RN Zone RA Zone RAA Zone R1 Zone R0 IdentP Resource/Service Site AzTickt SrvReq TA/BA Appl FW Requestor AuthN AuthZ Resource Resource/ Srvr/ (User) IF/Agent Service Contnr System (SRM) (DSE) User PEP DB (Access Control List) Attrib PDP PAP PAP Data AttrA SrvResp AzTickt Local UserDB FileSyst Internet/Network Site AuthN Site AuthZ Resource IF/GW Resource Access (Identity/Attributes) (Policy Enforcement) Resource Manager (Local File System) Resource Zone Security model for Grid/Web Services Grid Security

  6. Requestor Zone Security model for Grid/Web Services Grid Security

  7. Authentication, Delegation and Trust Management • Authentication deals with the process of verifying the identity, and attributes associated with a principal(s) within the Grid environment based on presented credentials (PKI, SAML, Kerberos tickets, password, etc.) • Based on X.509 Public Key Certificates (PKC) – RFC3280 • PKC issued by the Certification Authority (CA) as a third trusted party and confirms possession of the private key by entity • PKC based Authentication – user/client sends signed message or challenge together with PKC • Delegation (restricted and full) • Using X.509 Proxy Certificate (Proxy or PC) • Proxy is generated by the user client based on user master PKC or Proxy • Limited delegation chain (typically not more than 10) • Trust is an important component of PKI based AuthN • International Grid Trust Federation GridPMA – http://www.gridpma.org/ • Maintains a list of trust anchors, root certificates and related meta-information for all the accredited authorities, i.e., those that meet or exceed the criteria mentioned in the Authentication Profiles • Distributes also Certificate Revocation List (CRL) locations, contact information, and signing policies • Trust relations are represented by a certificate chain Grid Security

  8. X.509 Proxy Certificate (RFC3820) and Short Lived Credentials • Proxy Certificate is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system • Proxy Cert in Grid has limited life time – typically 24 hours, or less depending on purpose and target system • Can be used for access session management • Typical Proxy Certs chain PKC (DN1, CA) => PC (DN2, (ACa) , PKC) => PPC (DN2, (ACb) , PC) => … • Short Lived Credential (SLC) and SLC Service (SLCS) • Typical PKC is long lived about 1-5-10-30 years and requires special measures to protect it confidentiality • SLCS can be used for translating site/normal user credentials into SLC Grid credentials Grid Security

  9. OGSA Express Authentication Profile • Secure Communication Profile 1.0 • Extends WS-I Basic Security Profile and WS-SecurityPolicy 1.2 • Provides a framework for writing instant policies for WS/SOAP Message Level Security (MLS) Grid Security

  10. Virtualisation and Virtual Organisations (VO) in Grid • Grid resource and service virtualisation, together with provisioning, are two key concepts in the OGSA • OGSA Security is built around the Virtual Organisation (VO) concept and targeted for the enforcement of the security policies within a VO as an association of users and resources • VO provides a framework for inter-organisational and inter-domain trust management • When registered with a VO, an external user will be able to access to the enterprise/provider internal network based on his/her VO membership and relationship between the VO and the enterprise or provider • VO is actually a form of the user and resource federation that can dynamic by its nature Grid Security

  11. Security services in a Virtual Organization setting • Source: GFD.80 OGSA Security Architecture Grid Security

  12. VO structure and relationship with member organisations • VO provides a framework for bypassing (inter-) organisational barrier without violating security perimeter policies Grid Security

  13. VO security services interaction when processing a request inside a VO • VOMS plays role of the VO Identity Provider and Attribute Authority • VO AuthZ service is actually local site/resource AuthZ service that enforces VO AuthZ policy and accepts VO credentials Grid Security

  14. VO Membership Service (VOMS) in Grid AuthZ • Central for the VO • Reliability • Performance • Denial of Service (DoS) • Attribute Cert contains user VO membership and groups in FQAN format • PKC (DN1, CA) => PC (DN2, (ACvoa) , PKC) => PPC (DN2, (ACvob) , PC) => … Grid Security

  15. Fully Qualified Attribute Name (FQAN) • FQAN – a string containing VOMS group and optionally role information • Examples FQAN • /biogrid/analysis/Role=H5N1-admin • /biogrid/analysis • /biogrid/H5N10/Role=production • Examples matching rules Grid Security

  16. Authorisation at Computer Element (CE) – Example • LCAS – Local Center AuthZ Service • LCMAPS – Local Credentials MAPing Service • gLexec - gateway between Grid/site environment and executive Unix environment • Derivative from Apache suexec extended to support X.509 creds Grid Security

  17. CE Setup with shares and VOView Grid Security

  18. Matchmaking in VOView • The decision whether a given VOView supports a given job is taken as follows: • VOViewAccepted = ! cond1 && ( cond2 || cond3 || cond4 ) • where • cond1 = FQANmember(strcat("DENY:",other.VOMS_FQAN), • GlueCEAccessControlBaseRule); • cond2 = member(other.CertificateSubject, GlueCEAccessControlBaseRule) • cond3 = member(strcat("VO:",other.VirtualOrganisation), • GlueCEAccessControlBaseRule) • cond4 = FQANmember(strcat("VOMS:",other.VOMS_FQAN), • GlueCEAccessControlBaseRule) Grid Security

  19. Use Case for ‘gLExec on the WN’ – Pilot Job Make pilot job subject to normal site policies for jobs VO submits a pilot job to the batch system the VO ‘pilot job’ submitter is responsible for the pilot behavior this might be a specific role in the VO, or a locally registered ‘special’ user at each site Pilot job obtains the true user job, and presents the user credentials and the job (executable name) to the site (gLExec) to request a decision on a cooperative basis Preventing ‘back-manipulation’ of the pilot job make sure user workload cannot manipulate the pilot project sensitive data in the pilot environment (proxy!) by changing uid for target workload away from the pilot PilotJob UserJob User AuthN AuthZ glexec GW glexec WN LCAS/ LCMAPS LCAS/ LCMAPS SCAS Grid Security gLExec and OS integration – JRA1 All Hands February 2008 19

  20. Pilot Jobs and gLExec (EGEE AH meeting – 20-22 Feb 2008) On success: the site will set the uid/gid to the new user’s job On failure gLExec will return with an error, and pilot job can terminate or obtain other user’s job Grid Security 20

  21. gLexec deployment modes Identity Mapping Mode – ‘just like on the CE’ have the VO query (and by policy honour) all site policies actually change uid based on the true user’s grid identity enforce per-user isolation and auditing using uids and gids requires gLExec to have setuid capability Non-Privileged Mode – declare only have the VO query (and by policy honour) all site policies do not actually change uid: no isolation or auditing per user the gLExec invocation will be logged, with the user identity does not require setuid powers – job keeps running in pilot space ‘Empty Shell’ – do nothing but execute the command… Grid Security gLExec and OS integration – JRA1 All Hands February 2008 21

  22. Identity change in gLexec Let’s assume you make it setuid. Fine. Where to map to: To a shared set of common pool accounts Uid and gid mapping on CE corresponds to the WN Requires SCAS or shared state (gridmapdir) directory Clear view on who-does-what To a per-WN set of pool accounts No site-wide configuration needed Only limited (and generic) set of pool uids on the WN Need only as many pool accounts as you have job slots Makes cleanup easier, ‘local’ to the node Or something in between ... e.g. 1 pool for CE other for WN Grid Security gLExec and OS integration – JRA1 All Hands February 2008 22

  23. LCMAPS and grid-mapfile • grid-mapfile (normally /etc/grid-security/grid-mapfile) format "DN1" dteam "DN2" .dteam "/dech" .dech "/dech/Role=lcgadmin" dechsgm • Mapping from user DN# to local pool account • Mapping from user FQAN to local pool account Grid Security

  24. Authorisation: Obligations in Access Control and Management • Access control in Grid and Policy Obligations • Account mapping • Quota assignment • Environment setup/configuration • General Complex Resource provisioning • Fixed, Time-flexible, Malleable/”Elastic” Scheduling • Usable Resource • Other/general • Accounting, Logging, Delegation • Obligations in access control and policy based management • Obligated policy decision • Provisional policy decision Grid Security

  25. PilotJob UserJob User AuthN AuthZ glexec GW glexec WN LCAS/ LCMAPS LCAS/ LCMAPS SCAS Obligations and Pilot job use cases • Introducing SCAS as external AuthZ service called from protected environment changes simple security model • AuthN-AuthZ-glexec flow needs analysis • Behind each (SCAS) policy should be clear operational model • SCAS is verified to be compatible with the XACML policy and PDP • XACML uses pluggable security service model (i.e. called from major Service) • glexec is a kind of gateway/border device Grid Security

  26. Audit file Reference Monitor (RM) Security kernel OS database OSI-Security vs TCB Security • Trusted Computing Base (TCB) • Reference Monitor (RM) by J.P.Anderson “Computer Security Planning Study” (1972) • Models Bell-LaPadula and Biba • Certification criteria TCSEC/Common Criteria (1984) • A1, B1, B2, B3, C1, C2, D • Open Systems and Internet • Open Systems Interconnection (OSI) Security Architecture • ISO7498-2/X.800 • Independently managed interconnected system • Trust established mutually or via 3rd party • PKI and PKI based AuthN and key exchange • Concept of the Security Context Subjects Objects CA Trust relations Grid Security

  27. X.800/OSI Security – Layers vs Services vs Mechanisms • Similar model should be probably proposed for WS SOAP based security services and mechanisms • Layers model for above Application layer are uncertain Grid Security

  28. From OSI/Internet to SOA/WSA Security Model • X.800 Security Architecture for Open Systems Interconnection for CCITT applications. ITU-T (CCITT) Recommendation, 1991 • ISO 7498-2:1989 Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 2: Security Architecture • Web Services Security Roadmap (2002) • http://www.ibm.com/developerworks/library/specification/ws-secmap/ • OGSA Security Model Components (2002-2006) • GFD.80 - OGSA version 1.5, Section 3.7 Security Services • Re-states Web Services Security roadmap • WS-Security stds specifyusing SOAP header for security related issues • Considered as orthogonalto major service Grid Security

  29. Audit file Reference Monitor (policy) Security kernel, database Reference Monitor (RM) Concept • Proposed by J.P. Anderson in the report “Computer Security Planning Study” (1972) • RM property provides a basis for Multi-Level Security (MLS) • Complete mediation: The security rules are enforced on every access, not just, for example, when a file is opened. • Isolation: The reference monitor and databases must be protected from unauthorized modification. • Verifiability: The reference monitor’s correctness must be provable. That is, it must be possible to demonstrate mathematically that the reference monitor enforces the security rules and provides complete mediation and isolation. • RM concept is a basis for TCB certification Subjects Objects Grid Security

  30. Multi-Level Security Models • Biba model • No write up • No read down • Focus – Integrity • Applicability – (Open) Data and Control/Mngnt • Bell–LaPadula (BLP) model • No write down • No read up • Focus – Confidentiality • Mandatory Access Control • Applicability – Data • Known flaw – not protected against insider “worm” virus • TCSEC Common Criteria • A1 – B3 + formally/mathematically verified design • B1-B3 – Multilevel security, Formal security model, Mandatory AC • C1-C2 – Discretionary access control model, auditable user activity • D – minimal protection • Currently replaced by ISO 15408 Evaluation Assurance Level (EAL) Grid Security

  31. TCSEC/ISO Common Criteria TCSEC Certification Criteria A1 – B3 + formally/mathematically verified design B3 – Clear security model and layered design, Security functions tamperproof, Auditing mandatory B2 – Least-privilege access control model, Certifiable security design implementation, Covert channels analysis B1 – Labelled security protection, MAC-BLP + DAC C2 – Discretionary access control model, auditable user activity D – minimal protection Currently replaced by ISO 15408 Evaluation Assurance Level (EAL) EAL1: Functionally Tested EAL2: Structurally Tested EAL3: Methodically Tested and Checked EAL4: Methodically Designed, Tested and Reviewed EAL5: Semiformally Designed and Tested EAL6: Semiformally Verified Design and Tested EAL7: Formally Verified Design and Tested EAL1-4 – commercial systems, EAL5-7 - special systems (EAL4 circa C2) Windows NT (EAL4+) and many routing and Unix systems certified for EAL4 Grid Security

  32. Clark – Wilson Integrity Policy • Criteria for achieving data integrity (primary target for reliable business operation) - Authentication of all user accessing system - Audit – all modifications should be logged - Well-formed transactions - Separation of duties • Enforcement Rules • 􀁺 E1 (Enforcement of Validity) - Only certified TPs can operate on CDIs • 􀁺 E2 (Enforcement of Separation of Duty) - Users must only access CDIs through TPs for which they are authorized. • 􀁺 E3 (User Identity) - The system must authenticate the identity of each user attempting to execute a TP • 􀁺 E4 (Initiation) - Only administrator can specify TP authorizations • Certification Rules • 􀁺 C1 (IVP Certification) - The system will have an IVP for validating the integrity of any CDI. • 􀁺 C2 (Validity) - The application of a TP to any CDI must maintain the integrity of that CDI. CDIs must be certified to ensure that they result in a valid CDI • 􀁺 C3 - A CDI can only be changed by a TP. TPs must be certified to ensure they implement the principles of separation of duties & least privilege • 􀁺 C4 (Journal Certification) - TPs must be certified to ensure that their actions are logged • 􀁺 C5 - TPs which act on UDIs must be certified to ensure that they result in a valid CDI • TP – transformational procedure; IVP – integrity verification procedure; CDI – constrained data Item; UDI - unconstrained data Item Grid Security

  33. Developing Grid Security Model – Open issues and topics for R&D • Strong&consistent AthN is a good principle, BUT • Can be considered as sufficient only if a subject logs in the trusted environment (like server/UNIX) • There other security aspects • Use TCB (Secure OS) design principles • Layered design • Hardware, kernel, OS, user • Most sensitive operations in the (resource) innermost circle • Introduce security zones model • AuthN, (Delegation,) AuthZ, (AuthZ Session,) glexec/Unix • Keep security context • Use AuthZ session management concept and security mechanisms Grid Security

  34. Other Grid Security Issues - Open List • Re-factoring policy-based access control to policy-based object management • Many use cases in Grid job processing workflow fit better into generic policy based object management than to access control • Policy (and access conditions) are attached to the object (i.e. job) at its invocation and checked locally by glexec or RM • Policy based access control vs Managed Object policies • Virtualisation • Provides specific operational and security environment for security services • Trusted Computing Platform Architecture (TCPA) • Provides a basis for inter-connecting trusted computing hosts/environments • Defines Trusted Network Connect framework (TNC) • Allows combination with the Virtualisation platform to extend user-trusted environment to remote hosts Grid Security

  35. Zone RN Zone RA Zone RAA Zone R1 Zone R0 IdentP Resource/Service Site AzTickt SrvReq TA/BA Appl FW Requestor AuthN AuthZ Resource Resource/ Srvr/ (User) IF/Agent Service Contnr System (SRM) (DSE) User PEP DB (Access Control List) Attrib PDP PAP PAP Data AttrA SrvResp AzTickt Local UserDB FileSyst Internet/Network Site AuthN Site AuthZ Resource IF/GW Resource Access (Identity/Attributes) (Policy Enforcement) Resource Manager (Local File System) Resource Zone Security model for Grid/Web Services Grid Security

  36. Requestor Zone Security model for Grid/Web Services Grid Security

  37. PKI vs Identity Based Cryptography (IBC) • Uses publicly known remote entity’s identity as a public key to send encrypted message or initiate security session • Initially proposed by Shamir in 1984 as an alternative to PKI • Shamir is one of the RSA inventors in 1977 (Rivest, Shamir, Adleman) • Identity can be email, domain name, IP address • Allows conditional private key generation • Requires infrastructure different from PKI but domain based (doesn’t require trusted 3rd party outside of domain) • Private key generation service (KGS) • Generates private key to registered/authenticated users/entities • Exchange inter-domain trust management problem to intra-domain trust Grid Security

  38. IBC KGS IBC KGS IBC KGS AAA A IDC/AAA IDC/AAA IDC/AAA Service (AAA) plane R PAP PAP PAP PDP PDP PDP P Dest Host TVS TVS TVS Control plane PEP PEP PEP User Client DC/NRPS DC/NRPS DC/NRPS Appli- cation Network plane NE NE NE Agent Using IBC for key distribution in multidomain Network Resource Provisioning • Provisioning sequences • Agent (A) • Polling (P) • Relay (R) • Token based policy enforcement • GRI – Global Reservation ID • AuthZ tickets for multidomain context mngnt • NRPS – Network Resource Provisioning System • DC – Domain Controller • IDC – Interdomain Controller • AAA – AuthN, AuthZ, Accounting Server • PDP – Policy Decision Point • PEP – Policy Enforcement Point • TVS – Token Validation Service • KGS – Key Generation Service Grid Security

  39. Identity Based Cryptography (IBC) • Available implementations • Voltage Identity-Based Encryption (C based) • Used in Microsoft Exchange Server • Eyebee by Univ Ireland (Java) • Tested by us and will be implemented in IDC • Strong motivation for privacy concerned applications • E.g. patient-doctorcommunication Grid Security

  40. Questions and Discussion Grid Security

  41. AuthN/AuthZ in Grid/Web Service Environment • Message-level Security services are linked to SOAP header • Linking dynamically all components of the access control system • Policy is attached to any component of the service description in WSDL format • Interacting services will fetch policy document and apply restrictions/rules to elements, which declared policy compliance requirements Grid Security

More Related