1 / 12

Overview of local security issues in Campus Grid environments

Overview of local security issues in Campus Grid environments. Bruce Beckles University of Cambridge Computing Service. Overview. Organisational issues Authentication Authorisation Auditing (not Accounting) Rhys will talk about Accounting next Control access to the Campus Grid

dane-cote
Download Presentation

Overview of local security issues in Campus Grid environments

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. Overview of local security issues in Campus Grid environments Bruce Beckles University of Cambridge Computing Service

  2. Overview • Organisational issues • Authentication • Authorisation • Auditing (not Accounting) • Rhys will talk about Accounting next • Control access to the Campus Grid • Workstation issues: • Securing workstations (“nodes”) • Control the local environment • User issues

  3. Organisational issues • Need dedicated staff responsible for security of campus grid: • Must have or develop expertise in “grid security” – very much a moving target! • May be part of local IT security team • …If not, must work closely with IT security team • Automate, automate, automate!: • Automate deployment and monitoring procedures • …but periodically perform manual checks as well • Decide a security policy: • Prevention or Punishment? • What information must be collected to enforce / support this policy? (Auditing)

  4. Authentication • Why do we need authentication?: • Without it we have no idea who is using the Campus Grid • No way to tell authorised use from illegitimate use • Use your existing authentication infrastructure: • Kerberos, Active Directory, NIS, etc • Users are already familiar with it • Administration is handled by existing procedures and personnel • Avoid digital certificates and GSI. If you must use them: • Find (or create) a usable implementation • Make it completelytransparent to users • Remember it doesn’t scale well

  5. Authorisation • Needs low administrative overhead: • Develop quick, simple, usable procedures • Build in error checking! • Must scale well: • Centralised database with secondary servers • …Or distribute database automatically • Balance central control vs. delegated control: • Central control: • Clear where to apply for access • Tight control over who grants access • Easier to audit handling of access requests • Less vulnerable to “persuasion” • Delegated control: • Divisions more likely to know individual users • …but easier for user to “persuade” them to grant access • Periodically audit authorisation database

  6. Auditing (1) • Absolutely vital, but frequently overlooked • Determine what you need to audit to support your security policy • Analyse usage logs so you have some idea of what is “normal” for your Campus Grid • Analyse network traffic logs so you have some idea of what is “normal” for your network • Consider using an Intrusion Detection System (IDS) only if security staff already use one

  7. Auditing (2) • Current grid software not very good at it …but use whatever it gives you (usage logs, etc) • Use system’s auditing facilities wherever possible • Login records, process accounting (psacct), syslog, Windows Event Logs, etc. • Do not store audit trails on the local machine! • Consider keeping copies of users’ executables (but if you do this, make sure you let the users know)

  8. Control Access • Tightly control access points: • As few as possible • …but balance need for scalability • Ideally centralised • Must be under your control • Restrict user access to underlying grid middleware as much as possible • Develop usable front-ends for users: • Web portals • Interfaces to familiar queuing systems • etc

  9. Secure the workstation • Secure each individual workstation / “node” in Campus Grid: • A single insecure workstation can compromise the entire Campus Grid • So keep all software on workstations up to date! • Centrally manage workstations • Keep network services to a minimum • Tightly control software installed • Consider using sensible local firewalls (iptables, Windows Firewall, etc) with simple rule sets • Plan for a different attack profile: • A grid will attract different types of attacks (and attackers) than a managed workstation service • If your grid consists of managed workstations, then expect to get both types of attacks

  10. Control the local environment • Control local environment on workstation where jobs will run: • Restrict privileges of job processes (privilege separation, ACLs, etc) • Control network access if possible / practical • Sanitise environment before and after jobs run: • Start job with a clean environment • Delete temporary files, job’s data files, etc • Kill any extraneous processes • Run jobs in a sandbox / “virtual machine” if possible (but consider performance implications) • Make local environment uniform across each workstation OS

  11. User Issues • No users, no problem!: • So start small, with known, trusted users (of course, this doesn’t scale) • Then expand your user base gradually • Try to avoid a “our campus grid is open to all” policy • ‘Vet’ your users: • Ask for sample jobs and inspect them personally • Initially constrain new users to a small part of the Campus Grid • ‘Paranoia’: only allow them to run code you have approved • Know your users: • Try to get to know your users (not personally, although that helps), but their patterns of behaviour • How much do you trust them?

  12. Questions?

More Related