1 / 15

Secure Off Site Backup at CERN

Secure Off Site Backup at CERN. Katrine Aam Svendsen. Outline. Problem Related Work System at the start of the project System requirements System design Conclusions. Problem. How to develop a transparent and secure off site backup solution within the current systems at CERN?

helen-pierce
Télécharger la présentation

Secure Off Site Backup at CERN

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. Secure Off Site Backup at CERN Katrine Aam Svendsen

  2. Outline • Problem • Related Work • System at the start of the project • System requirements • System design • Conclusions

  3. Problem • How to develop a transparent and secure off site backup solution within the current systems at CERN? • How is this best implemented? • How should key management, policies and guidelines be designed? • Develop a user interface imposing as little inconvenience as possible to the user. • Is the security satisfactory with regards to the requirements to the system?

  4. Related work • Different encryption file systems: • CFS – Cryptographic File System • SFS – Secure File System • Farsite • TCFS – Transparent Cryptographic File System • Other sources: • Threats and vulnerabilities of storage systems • Key management • Policy writing • Disaster recovery

  5. System at the start of the project • Off Site Backup Service • Service to provide groups and services at CERN with the opportunity of storing a current copy of vital data, for disaster recovery purposes • Server: • Dual Intel Xeon 2,66 GHz CPU • 2 GB RAM • ~3TB storage space • Scientific Linux CERN 4 (SLC4)

  6. System requirements • System must offer the possibility of scheduled backups, but must also accept backup data from client machines at any time. • The system must be portable • The system must be easy to operate. The user must not need to enter a password to perform the backup • The data must be transferred securely • The data stored by one client must not be visible by any other client • The client must be able to restore the data at any time • The data must be secure if an adversary gains physical access to the server.

  7. System requirements • System must offer the possibility of scheduled backups, but must also accept backup data from client machines at any time. • The system must be portable • The system must be easy to operate. The user must not need to enter a password to perform the backup • The data must be transferred securely • The data stored by one client must not be visible by any other client • The client must be able to restore the data at any time • The data must be secure if an adversary gains physical access to the server.

  8. System design – Components • AFS servers: • Distributed computer environment • Available for several operating systems • Uses Kerberos for authentication • Possibility of traffic encryption • Off site backup server: • Installed TrueCrypt • Safe in secure location: • To store password for disaster recovery

  9. System design – TrueCrypt • Creates virtual encrypted disks and mount these as plain text disks • Volume file – can be managed as any other file (copy, move, rename etc.) • Volume partition/device – encrypts an entire partition or device (e.g. USB stick) • Providing the correct password or keyfile, a user can mount the volume on a desired mount point • The data stored in the volume are then accessible as any other plain text data

  10. System design – Key management • Encryption keys are created by TrueCrypt • Keyfiles are used to mount a volume, these are stored in AFS. Kerberos authentication is necessary to access the keyfile. • Volume is first created using a strong password, and volume header is backed up. The password is stored in a secure location, e.g. a safe, also off site. • Disaster recovery: Password is retrieved, volume header is restored, and the volume can be mounted.

  11. System design – Information flow when making a backup

  12. System design – Scripts • To lessen user inconvenience, scripts are developed: • To create a volume • To check if a volume is mounted • To mount and unmount a volume • To make a backup • To change keyfile • To restore the volume header

  13. System design – Policies and procedures • Policies and procedures have been designed, defining such things as: • Who is allowed to create new volumes? • How is the keyfile/password stored? • Who is allowed to access the keyfiles and password? • How is disaster recovery handled? • Who is responsible for controlling the access to the safe in the secure location? • What happens when a user leaves the organization? • Etc…

  14. Conclusions • A software tool such as TrueCrypt can successfully be used for secure backup encryption such as the one presented here. • Scripts are one way of decreasing the user inconvenience, combined with SSH using cryptographic keys and the keyfile functionality of TrueCrypt • The requirements to the security of the system is satisfied: • The data is transferred securely • The data stored by one client is not visible to any other client • The data is secure if an adversary gains physical access to the server. • Therefore, the security of the system is satisfactory. • The system is also adaptable to other situations.

  15. Questions?

More Related