DevSecOps: Secrets in the Cloud

移动互联 2018-06-18 阅读原文

You know that feeling when you tell someone a secret and then wonder if it is going to get out? (I mean, I have heard some people worry about that.)

Well, system operators managing security often (maybe always) worry that secrets used to access their networks and resources will get out or be set up incorrectly, exposing their systems.

If this describes someone you know, you can ease their worries with system hardening. Akash Mahajan ( @makash ) told his personal journey with system hardening in his talk, The Secrets in Our Clouds. Perhaps his experiences could help you implement or improve system hardening for you own system.

Akash is with Appsecco , which is a relatively small company with typical production and staging requirements:

  1. They run multiple web applications with integrated authentication
  2. They run multiple websites with authentication and authorization
  3. In most cases, they terminate SSL/TLS at Nginx and reverse proxy to internal apps
  4. They generate TLS certificates using Let's Encrypt
  5. Whenever they add authentication as a middleware they rely on an SSO provider
  6. Their apps which are running need access to certain secrets such as passwords and authentication tokens

Akash said he started his system hardening journey with, "what I know best: installing and configuring software". He chose Vault and Goldfish because of its well-written installation instructions and most of the complexity is hidden. Additionally, it seemed easy enough to expand.

Once your software is installed, you have to answer the question of where to store the secrets and what secrets do we need to worry about. Examples of secrets include:

  • Certificates
  • SSH keys
  • API tokens
  • Passwords (database, system, user, etc.)
  • Anything else you need to store safely, such as audit logs that may contain sensitive details and TOTP generation keys

After this was set up for Akash, he still had nagging doubts and gnawing fears in the back of his mind:

  • Is it the best way to manage secrets?
  • Should I be using something which is cloud-specific?
  • How resilient is this?
  • How will I automate to be able to make it reproducible?
  • What if I make a mistake in configuration and it leaks data out?
  • What if my backups fail?

What did Akash do? He switched hats from operations to security and didn't panic. He took a step back and thought of, "abstractions which are simple enough for me to understand." Some concepts that helped Akash include, plaintext keys, secure storage, secure access, and the ability to choose which users see which secret.

Some attributes that helped Akash:

  • If a digital secret is stolen, you still have your copy
  • The best way to store something that is important to you is in a form which is encrypted and not in plaintext
  • If we encrypt something, there exists a key which is in plaintext
  • This plaintext key needs to be protected
  • This plaintext key should have secure storage and we should be able to prove that we are authorized to access it when we want it
  • Our plaintext key can be stored inside the Vault behind keys which are with multiple people.
  • A cloud is someone else's computer. You can't store it in plaintext, but you can be rest assured AWS, Azure, etc. have done their security homework.

If you plan to store secrets in your cloud, Akash offered up a few things to think about:

  • Storage security - Can you expect to have better security than the cloud provider?
  • Access security - Can your internal processes do better security than the cloud provider?
  • Automation possibilities - If you do go ahead, what are the parts that will not be automated?
  • Cooking required - If you plan to have a multi-cloud strategy, do you need to write your applications, automation scripts to have wrapper functions to ensure that you can plug-in/plug-out cloud provider specific code?
  • Compliance - Do you have a specific compliance requirement which require you to think differently about all of this?

Akash wrapped up his talk with a recommendation to start simple with two approaches f or managing secrets: one for humans and another for systems. For humans:

  • Setup shared Keepass databases synced with each other
  • Setup a Vault server behind Nginx and create entries for SSH keys and database passwords
  • Use a provider which can match company directory to make it easy to revoke access to an employee if required

For systems:

  • Use the same cloud provider where your servers are based
  • If possible deploy a serverless app which exposes secrets both from the Cloud KMS and the Vault server.

If you want to hear Akash's full talk, you can watch it here.

If you are craving more on DevOps in Modern Infrastructure? Binge watch any of the 20 DevOps in Modern Infrastructure sessions, free of charge, from All Day DevOps .

Server Zone

责编内容by:Server Zone阅读原文】。感谢您的支持!

您可能感兴趣的

腾讯安全舰队亮相网络安全周 护航网络安全推动安全新生态... 腾讯科技讯 9月17日,由中央宣传部、中央网信办、教育部等九部门共同举办的,“网络安全为人民,网络安全靠人民”2017国家网络安全周,正式迎来“网络安全博览会暨网络安全成就展”。连续第四年参展的腾讯安全,也携旗下大业务矩阵,以及知道创宇、G...
Secureworks Recognized as a Leader by Independent ... ATLANTA–(BUSINESS WIRE)– Secureworks ® (NASDAQ: SCWX), a leading global cybersecurity company that keeps o...
网络安全专家:5G网络将面临更大攻击风险... 10月15日消息,专家警告称,5G虽然被称为未来的网络,其推出似乎迫在眉睫,但其超快系统仍存在严重的安全缺陷。 一组国际研究人员发现,5G系统引发了人们对下一代移动通信的“安全担忧”。这一新兴技术正在迅速推出,但专家...
Alphabet unveils Chronicle, a security company tha... ( Reuters ) — Alphabet Inc launched a new business unit on Wednesday that will sell cyber security software to Fortu...
Researchers steal bitcoin by exploiting SS7 vulner... Hackers have exploited a security weakness in global telecom networks to break into a GMail account, take control of a b...