Etikettarkiv: pingdom

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

Frukostmöte och lunchmöte

Idag så började jag dagen med ett möte med Carina Wigholm som är min affärscoach från inkubatorn CREATE här i Västerås/Teknikbyn. Hon hjälper mig och stöttar med diverse frågor och hjälp som kan behövas. Oftast handlar det om något nytt projekt där affärsidéer diskuteras. Carina jobbar till vardags som VD för bolaget Drumedar.

På lunchen så träffade jag Sam Nurmi som är en superentreprenör och har startat företag såsom Loopia och Pingdom. Vi diskuterade eventuella samarbeten och hur geolokaliseringstjänster såsom Gowalla och Foursquare tar mark, onlinedejting samt försäljningen av Loopia (2005?).

http://twitter.com/samnurmi/status/10288245746

Testa hastigheten på din webbtjänst

För att testa hastigheten på din webbserver så finns det ett antal olika alternativ, jag tänkte presentera några av dem här:

  • Företaget Load Impact som bl.a Rangar Lönn ligger bakom tillhandahåller en ”freeminum”-tjänst där du kan testa hur din webbtjänst klarar belastning.
  • Västerås-företaget (?) Pingdom som är grundat av Sam Nurmi presenterar svarstider på din webbserver på två olika ställen. Dels så får du en graf över de webbservrar som du övervakar samt så kan du testa deras verktyg här: tools.pingdom.com
  • Google Webmaster tools har en sida där du kan få information om hur lång tid det tog för Google Bot’en (nej inte Anna) att ladda din sida.
  • Apache Benchmark (aka ht) som jag bloggade om i Januari 2008
  • xDebug visar hur lång tid individuella sidor tar på sig att laddas och tillsammans med webgrind så får du ett snyggt webbgui som går igenom dina debugg-loggar

Vet du några andra sätt som det är möjligt att testa svarstider? Skriv en kommentar!