1 / 29

Grid Security in EGEE/LCG ISGC 2005, Taipei, Taiwan 29 April 2005

Grid Security in EGEE/LCG ISGC 2005, Taipei, Taiwan 29 April 2005. David Kelsey CCLRC/RAL, UK d.p.kelsey@rl.ac.uk. Introduction. The Grid aim Easy and open sharing of resources However Highly distributed resources and communities Independent administrative domains The Internet today

qamra
Télécharger la présentation

Grid Security in EGEE/LCG ISGC 2005, Taipei, Taiwan 29 April 2005

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. Grid Security in EGEE/LCGISGC 2005, Taipei, Taiwan29 April 2005 David KelseyCCLRC/RAL, UKd.p.kelsey@rl.ac.uk

  2. Introduction • The Grid aim • Easy and open sharing of resources • However • Highly distributed resources and communities • Independent administrative domains • The Internet today • An ever-increasingly hostile environment • Growing need for firewalls and other controls • Therefore need to convince • Computer Centres to allow Grid services • Developers & Users to take security seriously • Grid functionality versus Security • A major challenge! David Kelsey, Grid Security, ISGC 2005

  3. Outline • These slides are available at http://hepwww.rl.ac.uk/kelsey/kelsey29apr05.ppt • Security requirements • Security groups & requirements in EGEE • The Grid Security model • Authentication • Authorization & VO Management • Security Policy & Procedures • Operational Security • Security Service Challenges • Future plans • Final words David Kelsey, Grid Security, ISGC 2005

  4. Security Requirements • Users require • Open/easy access to cpu and data • Single Registration (once per VO) • Single Sign-On (login once per session) • Not to be bothered by security! • But they do need Availability and Data Integrity • Computer Centres/Security Officers require • Full local control of access to their resources • Knowledge of User details • Ability to audit (Who? What? When?) • Secure middleware, applications and services • Not to be bothered by security incidents David Kelsey, Grid Security, ISGC 2005

  5. Security requirements - Understanding how input from applications, sites and operations are handled. CA Coordination NA4 NA4 Middleware NA4 NA4 Solutions/Recommendations Req. JRA3 JRA1 Applications Req. Security Req. Req. Middleware Security Group Joint Security Policy Group Req. OSCT Req. “Joint Security Policy Group” defines policy and proceduresand inputs requirements to MWSG(For LCG/GDB and EGEE/SA1) (Cross Membership of US OSG Sec Team) Operations SA1 LCG OSG David Kelsey, Grid Security, ISGC 2005

  6. The Security Model David Kelsey, Grid Security, ISGC 2005

  7. The Security Model • Authentication – proof of identity • GSI: Globus Grid Security Infrastructure (interoperate) • Single sign-on via X.509 certificates (PKI) • Delegation (via short-lived proxy certs) to services • Global Authorization – right to access resources • Virtual Organisation (VO) – e.g. a Biomed experiment • Maintains list of registered users • Allocates users to groups and/or roles • Controls global policy and allocations • Local Authorization –site access control • Via local (e.g. Unix) mechanisms or • Callouts to local AuthZ enforcement (Grid developments) • Grid ACL’s - global identity or VO AuthZ attributes • Policy • Grids (e.g. EGEE, OSG) define security policy • Many stakeholders also contribute to “policy” David Kelsey, Grid Security, ISGC 2005

  8. Security Baseline assumptions • Be Modular and Agnostic • Allow for new functionality to be included as an afterthought • Don’t settle on particular technologies needlessly • Be Standard • Interoperate (GGF, WS-I, OSG, …) • Don’t roll our own, to the extent possible • Be Distributed and Scalable • “Central services are evil” • Always retain local control Slide from Olle Mulmo – EGEE-3 Athens 19 April 2005 David Kelsey, Grid Security, ISGC 2005

  9. Baseline assumptions • VOs self-govern the resources made available to them • Yet try to minimize VO management! • Use AuthN to tie policy to individuals/resources • An open-ended system • No central point of control • Can’t tell where the Grid ends • Best-effort solutions • rather than “appropriate” solutions Slide from Olle Mulmo – EGEE-3 Athens 19 April 2005 David Kelsey, Grid Security, ISGC 2005

  10. Security Policy Policy comes from many stakeholders Graphics from Globus Alliance& GGF OGSA-WG David Kelsey, Grid Security, ISGC 2005

  11. Authentication David Kelsey, Grid Security, ISGC 2005

  12. Authentication • Keep Authentication and Authorization separate • Authentication best done at Institute level • Authorization best done at VO level • Provide the User with one (Grid) electronic identity • For use in many Grid projects or VOs • For user convenience • Have successfully built a global PKI (X.509) • Mutual Authentication of people and services • What is the most appropriate scale? • One CA per country/region (ideally for all eScience) • EU Grid PMA has coordinated the (global) CA’s • “minimum requirements” for accredited CA’s • Now three worldwide PMA’s for Authentication • Asia/Pacific, The Americas and EU • International Grid Federation coordinates these • Federation agreement aimed for GGF in June 2005 David Kelsey, Grid Security, ISGC 2005

  13. EU Grid PMA CAs • Austria • Belgium • CERN • Cyprus • Czech Republic • Estonia • France • Germany • Greece • Hungary • Ireland • Italy • Nordic countries • Poland • Portugal • Slovakia • Slovenia • Spain • Switzerland • The Netherlands • UK Other Accredited CAs: • DoEGrids (USA) • GridCanada • ASCCG (Taiwan) • ArmeSFO (Armenia) • Russia • Israel • Pakistan TERENA TACAR repository(for root certificates) • Under consideration • Baltic Grid • Bulgaria • China – IHEP “Catch-all” CAs operated by CNRS (for EGEE) US DoE (for LCG) SEE-GRID (for SE Europe) David Kelsey, Grid Security, ISGC 2005

  14. Authorization and VO Management David Kelsey, Grid Security, ISGC 2005

  15. Authorization & VO Management • In EGEE gLite Release 1 • Global AuthZ (VOMS) • Virtual Organization Membership Service • VO members, their groups and roles • Provides digitally signed AuthZ “attributes” • Included in the grid proxy certificate • Local AuthZ • Local Centre Authorization Service (LCAS) • A framework to handle local policy (e.g. banned users) • Local Credential Mapping (LCMAPS) • Provides local credentials (Kerberos/AFS, ldap nss…) • Local policy decisions (CE and SE) • Can decide and enforce policy on VOMS attributes • n.b. LCAS/LCMAPS is just one local AuthZ service David Kelsey, Grid Security, ISGC 2005

  16. AuthZ – VOMS & LCAS high frequency low frequency CA CA CA host cert(long life) service user crl update user cert(long life) VO-VOMS registration registration VO-VOMS voms-proxy-init VO-VOMS proxy cert(short life) service cert(short life) VO-VOMS authz cert(short life) authz cert(short life) authentication & authorization info LCAS David Kelsey, Grid Security, ISGC 2005

  17. Security Policy David Kelsey, Grid Security, ISGC 2005

  18. EGEE/LCG Security Policy • During 2003/04, the LCG project agreed a first version of its Security Policy • Written by the Joint Security Policy Group • Approved by the Grid Deployment Board • A single common policy for the whole project • But does not override local policies • An important step forward for a production Grid • The policy • Defines Attitude of the project towards security and availability • Gives Authority for defined actions • Puts Responsibilities on individuals and bodies • Now being used by EGEE and (some) national Grids David Kelsey, Grid Security, ISGC 2005

  19. EGEE/LCG Security Policy (2) Under Revision picture from Ian Neilson Incident Response Certification Authorities Audit Requirements User AUP VO AUP Security & Availability Policy Application Development & Network Admin Guide User Registration & VO Management http://cern.ch/proj-lcg-security/documents.html David Kelsey, Grid Security, ISGC 2005

  20. Operational Security and Security Service Challenges David Kelsey, Grid Security, ISGC 2005

  21. EGEE Operational Security Coordination Team Operational Security • After LCG Workshop and EGEE2 Practical information for sys admins System monitoring tools Security Service Challenge Incident response Slide from Ian Neilson – EGEE-3 Athens 19 April 2005 EGEE3 Athens 21 April 2005 - 21

  22. Operational Security Coordination • Security Service Challenges • Objectives (https://edms.cern.ch/document/478367) • Evaluate the effectiveness of current procedures by simulating a small and well defined set of security incidents. • Use the experiences of a) in an iterative fashion (during the challenges) to update procedures. • Formalise the understanding gained in a) & b) in updated incident response procedures. • Provide feedback to middleware development and testing activities to inform the process of building security test components. Slide from Pal Anderssen – EGEE-3 Athens 21 April 2005 EGEE Athens 21 Apr 2005 - 22

  23. Future Plans EGEE Athens 21 Apr 2005 - 23

  24. Future plans Authentication • Many concerns about user-managed credentials • Too complex and too insecure • Several solutions to be considered • Smart Cards • Credential Repositories (e.g. MyProxy) • Long-term credentials never held by user • Site Integrated Proxy Services (SIPS) • e.g. Kerberos CA • Better certificate revocation technologies • E.g. OCSP David Kelsey, Grid Security, ISGC 2005

  25. Future plans (2) Other foreseen EGEE security developments include • Logging and Auditing • Authorization • Local policy decisions and enforcement • Standards based (OGSA-AuthZ) • Delegation • Data Key management • privacy & confidentiality • Isolation and Sandboxing • Dynamic Connectivity (Site Proxy) See EGEE Global Security Architecture https://edms.cern.ch/document/487004/ EGEE Site Access Control Architecture https://edms.cern.ch/document/523948/ David Kelsey, Grid Security, ISGC 2005

  26. Future plans (3) Security Policy and Procedures • Joint Security Policy Group • With OSG • Revise all security policy documents • Aim to make more general (wherever possible) • e.g. by working on joint documents • Today, too LCG-specific • Currently working on User AUP and VO AUP • See Bob Cowles’ talk Security Vulnerability Detection and Reduction • Look for and record known problems • Middleware and Deployment • And encourage speedy fixes • Work started in UK GridPP • Now collaborating with EGEE JRA3 David Kelsey, Grid Security, ISGC 2005

  27. Future plans (4) Operational Security • In Europe, EGEE OSCT will continue the work recently started • Incident Response • see Bob Cowles’ talk on OSG work • EGEE using same approach • Perform Security Service Challenges • Security Monitoring • Forensic Analysis • Best practice guides David Kelsey, Grid Security, ISGC 2005

  28. References • LCG/EGEE Joint Security Policy Group http://proj-lcg-security.web.cern.ch/ • EGEE JRA3 (Security)http://egee-jra3.web.cern.ch/ • Open Science Grid Securityhttp://www.opensciencegrid.org/techgroups/security/ • EU DataGrid Securityhttp://hep-project-grid-scg.web.cern.ch/ • LCG Guide to Application, Middleware and Network Securityhttps://edms.cern.ch/document/452128 • EU Grid PMA (CA coordination)http://www.eugridpma.org/ • TERENA Tacar (CA repository)http://www.terena.nl/tech/task-forces/tf-aace/tacar/ David Kelsey, Grid Security, ISGC 2005

  29. Final Words • Much has been achieved over recent years • Authentication • Authorization • Policy and Procedures • Operational Security • “Keep Security Simple” – or deployers & users will turn it off • But Grid middleware is less mature than Operating Systems • and see the many security patches for OS’s • Security incidents will happen • Well defined/agreed response procedures are essential • Grid services/middleware will need frequent security patches • Perhaps this will be the first sign of maturity? David Kelsey, Grid Security, ISGC 2005

More Related