DevOps Säkerhet

Att jobba med DevOps samt IT-säkerhet är några av de områden som jag gillar mest. Därför är det intressant att ibland stanna upp och reflektera. För inom DevOps handlar det oftast om att skeppa kod så snabbt som möjligt och bygga skalbara och snabba mikroinfrastrukturer med continuous integration. Säkerhet däremot ses ofta som en bromskloss i utvecklingsarbetet.

Det går att fuska med säkerhet: Genomföra saker snabbt men se säkerheten som ett lån med ränta. Att betala tillbaka på lånet snabbare gör att säkerheten blir bättre och det blir inte lika dyrt längre fram (technical debt).

Att ta med säkerheten tidigt i sin planering är viktigt, för använder ni Docker så se till att använda SELinux eller AppArmor (vilket bl.a. Ubuntu Snappy gör som standard).

Exponera ej Elasticsearch, Redis, MongoDB eller andra databaser direkt mot Internet, vilket tyvärr förekommer och nyttjas av elakingar.

Se även till att inte lagra lösenord i klartext och genomför säker radering av information. Visste du exempelvis att Mac OS X har kommandot srm?

srm – securely remove files or directories

Nu är det nog med rant för det blir faktiskt bättre. Och för att ge lite matnyttiga tips tänk på följande:

10 tips till säkrare DevOps

  1. Genomför inte bara backup. Kontrollera även löpande att den verkligen innehåller allt och fungerar. Backup för prod ska ej vara tillgänglig från stage och vice versa.
  2. Prod-, stage- och utvecklingsmiljöer ska ej dela nycklar, lösenord etc.
  3. Tänk på att ej lägga alla ägg i samma korg. Nyttja exempelvis Amazons availability zones.
  4. Kryptera så mycket som möjligt. Inte bara in-transit utan även lokalt, undvik helt klartextprotokoll samt införskaffa SSL-Certifikat.
  5. ossecLogga mycket och filtrera samt arkivera med hjälpmedel såsom OSSEC. Som förresten även kan hålla koll på filintegritet.
  6. Bevaka med verktyg såsom Nagios, Pingdom och New Relic. Glöm inte ändpunkter för API (10 saker som Bit.ly glömde att bevaka).
  7. Genomför löpande säkerhetskontroller med verktyg såsom QualysNessus och Detectity. Även manuella återkommande granskningar är att rekommendera av företag som utför penetrationstester.
  8. Omvärldsbevaka och håll Er uppdaterad när det kommer nya sårbarheter i de mjukvaror som Er infrastruktur använder. Vad är best practices just nu för att lagra lösenord, är det bcrypt, scrypt eller pbkdf2?
  9. Segmentera och filtrera så mycket som möjligt. Ingen enskild server eller konto ska ha tillgång till allt.
  10. Checka aldrig in lösenord, nycklar eller annat känsligt till ett repo.

Tänk inte bara DevOps, tänk även SecOps.

Lös inte nästa problem som du stöter på, på följande sätt (saxat från Stackoverflow)

https stackoverflow

2 reaktioner på ”DevOps Säkerhet

  1. Hej Jonas!

    Många kloka tankar i den här artikeln! Några tankar och kommentarer:

    Att ta med säkerheten tidigt i sin planering är viktigt, för använder ni Docker så se till att använda SELinux eller AppArmor (vilket bl.a. Ubuntu Snappy gör som standard).

    Absolut. Man ska dessutom inte förglömma att Docker inte är ett substitut för virtualisering. Kompartmentaliseringen är inte alls lika fullständig när det kommer till Docker. Om jag har förstått hela rätt så är root-access i en Docker-instans nästintill likvärdigt med root-access på föräldermaskinen. Har man känsliga Docker-instanser bör dessa läggas i separat virtuell maskin.

    Segmentera och filtrera så mycket som möjligt. Ingen enskild server eller konto ska ha tillgång till allt.

    En svårighet med dagens elastiska infrastruktur är dessa instanser kan komma och gå, vilket ställer nya krav på att också ha elastiska brandväggsregler på server-instanser. Detta går att lösa med olika service discovery-verktyg, men ställer samtidigt större krav på dessa verktyg; Vilka skydd finns det för att en ny okänd server påstår sig vara en tjänst den inte är?

    Checka aldrig in lösenord, nycklar eller annat känsligt till ett repo.

    Det ständiga problemet att sprida detta till alla utvecklare inom en organisation. Det krävs en enda commit.

    Kryptera så mycket som möjligt. Inte bara in-transit utan även lokalt, undvik helt klartextprotokoll samt införskaffa SSL-Certifikat.

    1. Använd asymmetriska krypton om möjligt. Det minimerar skadan vid intrång till maskiner som backar upp information och leder till betydligt starkare kryptering. Dessutom backup-integritet verifieras.

    2. Relaterat till min kommentar gällande verifiering av tjänster ovan; Inte att förglömma är att SSL/TLS också kan användas för verifiering med hjälp av certificate pinning. Det skyddar mot låtsas-tjänster på det interna nätverket.

    Sist, men inte minst, så anser jag att många av de DevOps-verktyg som gör att man skeppar kod snabbare också gör att man snabbare kan svara på säkerhetsproblem. Jag tänker på t.ex. konfigurationshanteringssystem á la Chef/Puppet/Ansible/SaltStack och deployment pipelines.

    Hörs,
    Jens

    PS. Jag har sett att du är anmäld på nästa KryptoParty. Jag hoppas att vi ses där och forsätter gärna den här diskussionen!

    PS. De tillåtna HTML-taggarna under kommentarsfälten är oläsliga ;)

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *