KMS at Okta - Intermediate Level
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,359 vues
I originally gave an advanced version of this talk at Amazon re:Invent. This is a more intermediate abridged version of the talk I gave at Eventbrite.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à KMS at Okta - Intermediate Level
Similaire à KMS at Okta - Intermediate Level (20)
Dernier
Dernier (20)
KMS at Okta - Intermediate Level
- 1. Jon Todd - @JonToddDotCom Encryption Key Storage with AWS KMS at Okta December 2015
- 2. 1 Background • Okta • Encryption • Why use a key server? 2 KMS Evaluation 3 Implementation
- 3. What is Okta? Okta is the foundation for secure connections between people and technology.
- 4. One platform, many use cases Centralized management of every user, app, device www.okta.com IT Enterprise-grade security built directly into your cloud apps developer.okta.com Developers
- 5. More than 3000 customers Education, Non-ProfitFinanceTechnologyCloudHealth Services Manufacturing , Energy Media Consumer
- 6. Used in 185 countries globally
- 8. Encryption
- 9. Encryption use cases • Fundamental • Confidentiality • Authenticity • Practical • Compliance • Least privilege principle
- 10. The problem with encryption Managing these
- 11. Alternative approaches to confidentiality • Use cases for hashing instead of encryption • Authentication • Correlation • Use cases without needing keys • Homomorphic applications • Ordering, range query (for example, CryptDB) • Only require encrypt • Use asymmetric crypto • Trust No One (client encryption scenarios) • File storage or password vault
- 12. Why use a key server?
- 13. Example application Requirements: 1. Data in database is encrypted at rest and in memory 2. Encryption keys reside only in memory 3. Service has access to the plaintext data Client Service +
- 14. Where do we get the keys from? • At server startup • Environment variable • File • At run time • Over JMX + TLS • Over SSH • Key service
- 15. Key service • Separation of duties • Auditable • Easy rotation of master key • Data key in memory for very short period • Centralized master key never leaves key service + Client Service Master key Encrypt Key Service DB
- 16. 1 Background • Requirements • How KMS works • KMS threat model 2 KMS Evaluation 3 Implementation
- 17. Encryption use cases • Privacy of user data • Protection of PII, PCI, PHI • Credential storage • SAML keys • OAuth tokens • Third-party application credentials
- 18. Requirements • Strong encryption 256 bit AES GCM Strong random-number generator • Separation of duties By design Quorum management of servers • Support auto-scale through secure bootstrapping Hypervisor bootstraps IAM keys • Auditability Encryption context + CloudTrail
- 19. How KMS works
- 20. KMS Operations • randomKey = generateDataKey(keyId, encryptionCtx) • ciphertext = encrypt(plaintext, keyId, encryptionCtx) • plaintext = decrypt(ciphertext, keyId, encryptionCtx) Service CMK42 generateDataKey(CMK42, context) KMS 3 2 1 DK Decrypt + Service CMK42 kmsDecrypt(ciphertextDK, keyId, Context) KMS 4 1 3 2 DK Ciphertext Envelope = Encrypt + Service CMK42 kmsEncrypt(keyId, Context) KMS 3 4 2 1 DK Plaintext Ciphertext Envelope No plaintext!
- 21. Threat model: KMS with EC2
- 22. + Client EC2 instance Master key Encrypt KMS DB Data key
- 23. Getting IAM credentials for KMS • Credentials granted via IAM Role • Hypervisor provides a per-instance metadata service • Security considerations • Metadata service is accessible by all users • Credentials aren’t channel bound • Credentials are short lived
- 24. IAM credentials via metadata service curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyApp { "Code" : "Success", "LastUpdated" : "2015-08-20T21:17:41Z", "Type" : "AWS-HMAC", "AccessKeyId" : “SOME_ACCESS_ID", "SecretAccessKey" : ”SOME_SECRET_ACCESS_KEY", "Token" : “SOME_SIGNED_TOKEN", "Expiration" : "2015-08-21T03:22:28Z" }
- 25. IAM credential rotation • Credentials expire in ~ 6 hours • Credentials are rotated every ~ 1 hour Current Time: 2015-08-20T22:14:52Z LastUpdated: 2015-08-20T21:17:41Z Expiration: 2015-08-21T03:22:28Z Current Time: 2015-08-20T22:29:39Z LastUpdated: 2015-08-20T22:18:48Z Expiration: 2015-08-21T04:47:30Z
- 26. Threat model: KMS transport + Client EC2 instance Master key Encrypt KMS DB Data key
- 27. Transport Security • TLS for confidentiality and authentication of server • “A” rating on Qualys SSL Labs • Disallowed protocols SSL2 & SSL3 • Supported protocols TLS 1.0, 1.1, 1.2 • Forward secrecy required • Verisign root CA • IAM Signature V4 for authN and authZ of client
- 28. Threat model: KMS + Client EC2 instance Master key Encrypt KMS DB Data key
- 29. KMS key hierarchy • CMK – Customer master key • HSA – Hardened security appliance • EKT – Exported key token • HBK – HSA backing key • CDK – Customer data key • CT – Customer token Source: KMS Cryptographic Details
- 30. Threat model – final comparison • AWS CloudHSM • HSM at cost of managing High Availability (HA) • Low performance • DIY • Roll your own credential management and rotation • Separate operational team • No access to hardware/TPM Low Risk Low Cost High Cost High Risk DIY KMS Cloud HSM
- 31. 1 Background • Goals • Failure mitigation • Authorization & auditing • Rollout & tuning 2 KMS Evaluation 3 Implementation
- 32. Implementation goals • Multiregion support for disaster recovery (DR) • Mitigate total KMS failure • Avoid vendor lock-in • Minimal performance impact • Operational tools for key rotation
- 34. Multiregion encryption and decryption • Encrypt & store tenant key encrypted by each region key • Decrypt talks to closest KMS region • RSA public key used for encrypt only • Private key provided to service only in event of KMS outage Service KMS East KMS West Region master keyRegion master key Tenant master key RSA Key Region master key DB
- 35. September 20th KMS increased error rate
- 36. Okta failed-over automatically KMS requests by region https://trust.okta.com
- 38. Encryption context • Features: • Additional authenticated data (AAD) via AES GCM • Logging – Understand why the key was accessed • Authorization – Fine-grained access control to data keys • Okta’s implementation • Type: <ServiceName>.<EntityName> • Id: <EntityId> • A good encryption context identifies or classifies • Think carefully about mutability and storage of context • Encryption context shouldn’t contain sensitive data
- 40. CloudTrail
- 42. Rollout and TTL tuning TuningGradual rollout
- 43. Performance
- 44. Region failovers • ~ 0.001% failure rate without tuning HttpClient retries • At retry value of 3, failure rate is negligible
- 45. SDK client tuning kmsClientConfig = new ClientConfiguration() .withSocketTimeout(3000) // 3 seconds .withConnectionTimeout(3000) // 3 seconds .withConnectionTTL(60000) // 1 minute .withMaxErrorRetry(3); client = new AWSKMSClient(kmsClientConfig);
- 46. Final thoughts
- 47. Implementation recommendations • You may not need encryption or keys for confidentiality • Put thought into encryption context • Reconcile CloudTrail logs with application logs • Tune the SDK for timeout and retries • Consider an extended key hierarchy
- 48. Reference • User-Based and Resource-Based Permissions – http://docs.aws.amazon.com/IAM/latest/UserGuide/policies_permission s.html#TypesPermissions • AWS Key Management Service Cryptographic Details – https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf • KMS Developer Guide – http://docs.aws.amazon.com/kms/latest/developerguide/kms-dg.pdf
- 49. Okta for developers Universal Directory Single Sign-On Provisioning Adaptive Multi-factor Authentication Social Authentication Inbound Federation AD and LDAP Integration
- 50. Thank You. Find me on twitter www.okta.com@JonToddDotCom Learn more about Okta
Notes de l'éditeur
- Here you can see the end user SSO experience of Okta works both in a browser and natively on your mobile devices
- Okta enables a whole host of identity functionality. At it’s most basic we have two target audiences…
- Since our product launch 5 years ago we’ve gained a lot of momentum Customers across all major verticals Including Eventbrite! Scale Manage 10’s of millions of identities on a multi-tenant architecture built entirely in AWS Team of about 600 people and about 130 people in engineering
- Java backend JS Front end Entirely hosted in the cloud in AWS In general we like using and giving back to open source
- LPP is defense in depth.
- Encryption makes your data confidential but then you’re left with a problem. What do you do with the keys? Encryption merely pushes the problem down to a smaller surface to protect
- So before dealing with keys and key management. Consider alternate means of confidentiality … Now if none of these apply to your application and you actually do need access to the plaintext data then we need a good solution to manage keys
- Describe the model At rest – Compliance In memory on the DB – Least privilege principle. DBAs don’t need access to secrets
- Bootstrapping credentials for KMS
- Closing: There could be improvements Bootstrapping and rotating credentials is hard if you were to do it yourself More importantly AWS has the advantage with access to hardware leveraging what might be available like a TPM
- Customer Master Key is a logical concept Over the life of that MK there will be rotations, each with a new HBK Operation is similar to an HSM The actual keys performing encryption live in the HSA Nothing leaves the HSA in plaintext More details in the Cryptographic White Paper
- Pricing: KMS < $1000 per month CouldHSM > $20k per month not factoring management and HA design time DIY - > $200k up front plus $10k on going
- Each tenant master key is rooted in 3 encryption providers
- N. Virginia was the only affected region
- How did Okta do? Okta failed over automatically Where the yellow meets the blue
- Hammer home why this helps you. – YOU NEED TO KNOW WHY YOUR KEYS WERE USED Note that the ID is internal so it would be meaningless if someone owned the AWS side
- We use policy because our key management model is static For a dynamic access control model they also offer Grants
- Consider hashing, asymetric, homomorphic & trust no one models instead Ask: Does my app actually need to operate on the plaintext? Encryption Context Hard to change later Think identification and classification Immutable, stored with encrypted data is easiest Hierarchy: Removes vendor lock-in enables multiple trust roots and failover comes at cost of complexity
- IAM Config Security details Developer guide for writing code
- Okta helps developers Connect with customers – AD, LDAP, Federation Secure your product (auth & mfa)