Security in Storage Networks A Current Perspective

Transcription

1 Security in Storage Networks A Current Perspective Christian Cachin <cca@zurich.ibm.com> ZISC Colloquium

2 Overview Networked storage systems NAS, SAN, OBS Design options for security data in flight & data at rest SAN filesystems Cryptographic SAN filesystem Summary 2 ZISC Colloquium 2004 IBM Corporation

3 Traditional Storage Systems app fs inode blk hba Direct-attached Storage 3 ZISC Colloquium 2004 IBM Corporation

4 Networked Storage Systems: NAS, OBS, SAN app app app fs fs fs fs inode inode inode inode NFS, CIFS (TCP/IP) blk hba OBS Protocol blk hba blk blk hba FC, iscsi NAS (Network-attached Storage) Object Storage (OBS, proposed to SNIA ) SAN (Storage-area Network) 4 ZISC Colloquium 2004 IBM Corporation

5 Network-based Storage Devices File server - read & write data in file - create & destroy file - directory operations - file/dir-based access control - space allocation - backup ops Object storage dev. - read & write bytes in object - create & destroy object -- - object-level access control - space allocation - backup ops Block device - read & write blocks device-level access control ZISC Colloquium 2004 IBM Corporation

6 Security in Networked Storage Systems Existing technology offers little protection Server room only Trusted storage providers, works, and clients Coarse-grained access control Security is needed Storage as a commodity Networked storage to desktop (iscsi) Threats - physical access to disks - access to work - authorized machines - unauthorized machines 6 ZISC Colloquium 2004 IBM Corporation

7 Security Toolbox Goals Confidentiality (no unauthorized access) Integrity (no unauthorized modification) Availability Mechanisms Encryption Confidentiality based on shared key k E k E k Message-authentication code (MAC) Integrity based on shared key k M k M k Hashing and digital signatures Integrity, w.r.t. reference value v H v Access control Confidentiality, integrity, availability Any mechanism on any layer, and in combination with others. 7 ZISC Colloquium 2004 IBM Corporation

8 Two Options for a Security Design 1) Protect the work - data in flight app... fs/obj/blk fs/obj/blk... hba 8 ZISC Colloquium 2004 IBM Corporation

9 Two Options for a Security Design 1) Protect the work - data in flight app... fs/obj/blk fs/obj/blk 2) Protect the data path - data at rest... hba 9 ZISC Colloquium 2004 IBM Corporation

10 Protecting Data in Flight Security in work/transport layer IPSEC, secure RPC... app... Access control on corresponding storage layer fs/obj/blk fs/obj/blk NAS at filesystem layer M E E M... AFS, NFSv4 hba ObjectStore at object layer NASD [Gibson et al./cmu], ObjectStore [Azagury et al./ibm] SAN at block layer Snapdragon [Aguilera et al./hp SRC] 10 ZISC Colloquium 2004 IBM Corporation

11 Protecting Data in Flight: Object Storage Link security on SAN - secure channel established by admin Protects data in flight Decrypts data on storage side admin Protection of object access at storage device client M E E M - access control through credentials - (cryptographic) capabilities by admin No unauthorized actions on data Requires new storage interface 11 ZISC Colloquium 2004 IBM Corporation

12 Protecting Data at Rest Encryption Integrity verification Access control Depending on storage layer: Cryptographic filesystems app fs/obj/blk cfs [Blaze], cepheus [Fu/MIT], SFS [Mazières et al./ MIT&NYU], EFS [W2k] & rest of the talk!... M E fs/obj/blk... hba Cryptographic Object Storage SAN encryption Security applicances [Decru, NeoScale, KastenChase] 12 ZISC Colloquium 2004 IBM Corporation

13 Protecting Data at Rest Encryption: keys? separate security admin server encrypted with user/group public key held by hardware module Integrity verification: reference values? integrated in directory inode tree is hash tree app... M E fs/obj/blk digital signatures under user/group public-key Access control: credentials? separate security admin server (Kerberos, ObjStore admin) fs/obj/blk... hba 13 ZISC Colloquium 2004 IBM Corporation

14 Protecting Data at Rest: A Cryptographic SAN Filesystem 14 ZISC Colloquium 2004 IBM Corporation

15 Protecting Data at Rest: A Cryptographic SAN Filesystem SAN today: Clients access block storage devices directly Fibre Channel (SCSI) Static configuration OS sees a local block storage device Static access control zoning & fencing in FC switch Inside server room only client client SAN 15 ZISC Colloquium 2004 IBM Corporation

16 SAN Filesystems (e.g. IBM's StorageTank) Virtualized block storage space Block access managed by metadata server (MDS) Single filesystem name space Heterogeneous clients Un*x client app vfs W2k client app vfs metadata blk blk LAN MDS (clustered) SAN 16 ZISC Colloquium 2004 IBM Corporation

17 Design of a Cryptographic SAN Filesystem Integrity verification & encryption in client Scalable End-to-end security MDS is trusted, provides encryption keys & reference data Integrate key management with metadata No modification of storage interface Needs secure LAN connection MDS LAN client H E client H E SAN 17 ZISC Colloquium 2004 IBM Corporation

18 Confidentiality Protection Data is encrypted on client Data encrypted in flight and at rest Metadata server holds keys, one key per file/object Selective, fine-grained activation Storage interface unmodified Impossible to prevent overwrites AES (e.g.) MDS client E k client E k SAN NIST standard (2001), fast & secure ~ 80MByte/s in software (Xeon 3GHz) Key evolution Fresh key on data rewrite 18 ZISC Colloquium 2004 IBM Corporation

19 Key Evolution in Cryptographic Filesystems Knowledge of Key = Access to data Key revocation & key evolution Grant access Hand out key Revoke access Change key... expensive! Re-encrypt complete file with fresh key Do nothing as long as no data is written Fresh key for freshly written data 19 ZISC Colloquium 2004 IBM Corporation

20 Integrity Protection Data is hashed on client to digest values Digest values stored at MDS Secure transfer of digests Integrity protected in flight and at rest, modifications are detected Storage interface unmodified Impossible to prevent overwrites, but violations are detected SHA-1, SHA-256 or others MDS v H v H SAN NIST standards, fast & secure ~ 260 MByte/s in software (Xeon 3GHz) Granularity? Incremental updates? Design alternatives 20 ZISC Colloquium 2004 IBM Corporation

21 Integrity Protection: Design Alternatives Assumption: MDS trusted Design 1: Digests of all files stored by MDS + Simple + Little storage overhead at MDS (SHA-256: 32 bytes per file) Updates require recalculation of digest, work proportional to file length Integrity can only be verified after entire file has been processed; partial reads inefficient Design 2: Digests stored by MDS, using incremental hashing + Almost as simple as Design 1 + Incremental updates, work independent of file length + Little storage overhead at MDS (SHA-256: 32 bytes per file) Integrity can only be verified after entire file has been processed; partial reads inefficient Somewhat slower than Design 1 21 ZISC Colloquium 2004 IBM Corporation

22 Integrity Protection: Design Alternatives (2) root Design 3: Hash tree [Merkle], stored by MDS + Incremental updates with logarithmic work + Verification of partial reads Storage and data transfer overhead at MDS (linear in file size / degree of tree) H H H H H H H H H H H H H H H H H H H Design 4 (choice): Hash tree, tree stored on SAN, root by MDS + All advantages of above + Almost no overhead at MDS + Extensible to NFSv4 named attributes or NTFS streams 22 ZISC Colloquium 2004 IBM Corporation

23 Integrity Protection with Author Attestation User signs file data Implementation on top of hash tree by signing root Provides partial audit trail (last writer) Reference storage Data retention allows full audit trail Key management requires a public-key infrastructure Associate keys with file system users Use existing PKI (PGP, X.509) Keys and certificates managed by clients MDS only storages keys, needs not be trusted 23 ZISC Colloquium 2004 IBM Corporation

24 Comparing the Two Options Protecting data in flight + well-established work security tools + access control at storage device stored data is not encrypted / verified needs new storage device interfaces Protecting data at rest new mechanisms no prevention of overwrites + end-to-end security for stored data (data in flight & at rest) + scalable, data is encrypted / verified only once + transparent to storage device Combination is possible in particular when implemented at different layers 24 ZISC Colloquium 2004 IBM Corporation

25 Summary Networked storage systems NAS, ObjectStore, SAN Design options for security Protecting data in flight Protecting data at rest Recent trends ObjectStore Cryptographic SAN Filesystems 25 ZISC Colloquium 2004 IBM Corporation

26 Thank you! More information? 26 ZISC Colloquium 2004 IBM Corporation