Embed Size (px)
Citation preview
Barbican1.0 K!" #$%$&!#!%' f(r ')! (*!% +,(-.
J$rr!' R$/# & M$'' T!0$-r(
aboutus
DEVELOPER
ACADEMIC
SECURITY ARCHITECT
SECURITY CONSULTANT
SECURITY PRODUCTS
OWASP BOARD MEMBER
OWASP LIVE CD
OWASP WTE
RACKER SINCE ‘11
PRODUCT SECURITY
HACKING THE RACK
Ev!r"(%! wr/'/%& +(.! %!!.0 &((. 1!" #$%$&!#!%'
CustomerS
57%!
19%!
11%!
7%!
4%!
2%!
13%!
11%!
18%!
27%!
18%!
13%!
2%!
16%!
9%!
18%!
27%!
27%!
Data Protection!
Endpoint & Network Protection!
Identity & Access Control!
Application Security!
Vulnerability & Incident Management!
Configuration & Patch Management!
Most important security technologies for a hoster to provide !
#1 Choice!#2 Choice!#3 Choice!
73%
46%
38%
52%
49%
42%
Ev!r" O*!%S'$+1 *r(2!+' )$0 !%+r3'/(% %!!.0
OpenStack Swift & Glance Encrypted files at rest.
Trove Encrypted databases and tables.
Neutron SSL Certificates and VPN keys.
Nova & Ironic SSH keys, encrypted file systems.
Keystone Encrypted metadata, user level keys.
Cinder Transparent volume encryption.
Heat AES, SSH & SSL key management.
Marconi Encrypted queue messages.
Savanna Analytics on encrypted data.
OSLO Support all the things.
Customdev Settings Commonly exposed settings including credentials can be protected either through encryption or by storing the entire settings file.
Encryption Keys Keys used to provide encryption for data at rest.
SSL Keys SSL / TLS private keys.
SSH Keys Keys used for access control.
Transparent Encryption
Federated Keys
On-Premise Management
InteractionMOdels
Least secure Most secure
Transparentencryption
Public
Private
Consuming Service
Customer Rackspace
Public
Private
FEderatedKeys
Public
Private
Consuming Service
Customer Rackspace
Public
Private
OnPRemise
Public
Private
Customer Rackspace
Public
Private
VagrantUp
KeySTorage
All keys are encrypted with a tenant-level key encryption key (KEK). This key never leaves the HSM (if using one). The encrypted data encryption key (DEK) is stored in the Barbican data store.
Barbican API Node
Hardware Security Module
Data Store
KEK DEK
DEK
4! 1!"/%& #$'!r/$,
SecretResource POST v1/{tenant_id}/secrets !!{ ! "name": "AES key", ! "expiration": "2014-02-28T19:14:44.180394", ! "algorithm": "aes", ! "bit_length": 256, ! "mode": "cbc", ! "payload": "gF6+lLoF3ohA9aPRpt+6bQ==", ! "payload_content_type": "application/octet-
stream", ! "payload_content_encoding": "base64"!} !
GET v1/{tenant_id}/secrets/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718 !
!{ ! "status": "ACTIVE", ! "updated": "2013-06-28T15:23:33.092660", ! "name": "AES key", ! "algorithm": "AES", ! "mode": "cbc", ! "bit_length": 256, ! "content_types": { ! "default": "application/octet-stream"! },! "expiration": "2013-05-08T16:21:38.134160", ! "secret_href": "http://localhost:8080/
v1/12345/secrets/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718", !
} !
4! 1!"/%& #$'!r/$,
OrdersResource POST v1/orders !!{ ! "secret": { ! "name": "secretname", ! "algorithm": "AES", ! "bit_length": 256, ! "mode": "cbc", ! "payload_content_type": "application/octet-
stream" ! } !} !
GET v1/orders/f9b633d-…-80289e !!{ ! "secret": { ! "name": "secretname", ! "algorithm": "aes", ! "bit_length": 256, ! "mode": "cbc", ! "payload_content_type": "application/octet-
stream" ! },! "order_href": "http://localhost:8080/
v1/12345/orders/f9b633d8--5b2c9280289e", ! "secret_href": "http://localhost:8080/
v1/12345/secrets/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718"!
} !!
SwiftDemo Tr$%0*$r!%' !%+r3'/(% f(r (b2!+' 0'(r$&!.
portcullisproxy
Key Per File Portcullis currently uses a single key per encrypted file. This is to deal with copy between container semantics in Swift.
Filename & Container Names We don’t currently encrypt filenames and container names. This is to ensure that all tools that expect Swift semantics still work.
HMAC /verify resource We currently use AES-CBC with HMAC. We’ll move to GCM as soon as the code is stable. We have a new /verify resource that clients can use to check integrity.
Flow Control Pyrox performs the necessary flow control functionality that needs to happen to keep the proxy from being overwhelmed.
Pyrox is a HTTP reverse proxy that can intercept requests ahead of an upstream HTTP REST service. This allows reuse of common middleware functions like: message enhancement, dynamic routing, authentication, authorization, resource request rate limiting, service distribution, content negotiation and content transformation. These services can then be scaled horizontally separate the origin REST endpoint.
Futurework KMIP Support There is a possibility that a Python KMIP client will be open-sourced by Safenet soon. If so, we’ll integrate it, if not, we’ll build our own.
SSL / TLS Barbican will support the provisioning of SSL certificates from internal and external CAs.
Federation Support for federated keys in both Barbican to Barbican and Barbican to HSM configurations.
Integrations Barbican will help teams integrate to provide encryption services.
IntegrateNow Python-Barbicanclient Provides both a programmatic and command line interface to a Barbican instance.
Source Code & Documentation The documentation and source code both reside on GitHub in the CloudKeep organization. Blueprints and project documentation is on Launchpad.
Integration Environment Barbican maintains an integration environment on Public Cloud for testing. Not for use in production deploys, but usable for testing / dev.
from barbicanclient import client !!barbican_client = client.Client(endpoint='http://path-to-
barbican', tenant_id='tenant_id_for_context') !!barbican_client.secrets.store(name, payload,
payload_content_type, payload_content_encoding, algorithm, bit_length, mode, expiration) !
!barbican_client.orders.create(name, payload_content_type,
algorithm, bit_length, mode, expiration) !
usage: keep [-h] [--no-auth | --os-auth-url <auth-url>] !"[--os-username <auth-user-name>] [--os-password <auth-password>] [--os-tenant-name <auth-tenant-name>] [--os-tenant-id <tenant-id>] [--endpoint <barbican-url>] !"<entity> <action> ... !
