Nemrég az Elastic blogján , amelyben bejelentették, hogy az Elasticsearch főbb biztonsági funkciói, amelyeket több mint egy éve hoztak nyílt forráskódú környezetbe, most ingyenesek a felhasználók számára.
A hivatalos blogbejegyzésben "helyes" szavak találhatók, miszerint a nyílt forráskódnak ingyenesnek kell lennie, és hogy a projekt tulajdonosai a többi kiegészítő funkcióra alapozzák üzletüket, amelyeket az enterprise megoldásokhoz kínálnak. Most a 6.8.0 és 7.1.0 verziók alapkiadásába beletartoznak a következő biztonsági funkciók, amelyek korábban csak arany előfizetés keretein belül voltak elérhetők:
- TLS a titkosított kapcsolatra.
- Fájl- és natív reálm a felhasználói fiókok létrehozására és kezelésére.
- Felhasználói hozzáférés kezelés API-hoz és klaszterhez szerepkörök alapján; többfelhasználós hozzáférés megengedett a Kibana-hoz a Kibana Spaces használatával.
A biztonsági funkciók ingyenes szekcióba való áthelyezése azonban nem nagylelkű gesztus, hanem annak a próbája, hogy távolságot teremtsenek a kereskedelmi termék és annak legfőbb problémái között.
Pedig vannak, és nem is csekélyek.
A "Elastic Leaked" keresésre a Google 13,3 millió találatot ad. Imponáló, nem igaz? A biztonsági funkciók nyílt forrássá tételét követően, ami valaha jó ötletnek tűnt, az Elastic súlyos adatszivárgási problémákkal szembesült. A lényeg, hogy az alap verzió szita lett, mivel senki sem támogatta ezeket a biztonsági funkciókat rendesen.
Az egyik legnagyobb adatszivárgás az elastic szerverrel kapcsolatban az volt, hogy 57 millió amerikai polgár adatait veszítették el, amiről 2018 decemberében (később kiderült, hogy valójában 82 millió rekord szivárgott ki). Akkor, 2018 decemberében, az Elastic biztonsági problémái miatt Brazíliában 32 millió ember adatai lopták el. 2019 márciusában egy másik elastic szerverből összesen 250 000 bizalmas dokumentum szivárgott ki, köztük jogi jellegű anyagok. És ez csak az első oldal a megemlített keresési találatok közül.
Valójában a hackelések még mindig folytatódnak, és nem sokkal azután kezdődtek, hogy a fejlesztők maguk tették "kívülállóvá" a biztonsági funkciókat és átültették őket nyílt forráskódba.
Az olvasó észlelheti: "Na és? Igen, vannak biztonsági problémáik, de kinek nincsen?"
Most pedig figyelem.
A kérdés az, hogy ezen a hétfőn az Elastic szabad lelkiismerettel szedett pénzt az ügyfeleitől egy szűrőért, amit security-funkciók néven nominált, amelyeket ő maga bocsátott ki nyílt forráskódúvá 2018 februárjában, tehát körülbelül 15 hónappal ezelőtt. Nem viselve semmilyen lényeges költséget ezeknek a funkcióknak a fenntartásáért, a cég rendesen pénzt szedett a gold és premium előfizetőktől a vállalati szegmensből.
Hogy mikor, a biztonsági problémák olyan mérvűen váltak toxikussá a cég számára, hogy az ügyfelektől érkező panaszok fenyegetővé váltak, a kapzsiság háttérbe szorult. Azonban ahelyett, hogy újraindították volna a fejlesztéseket és "betömték" volna a lyukakat a saját projektjükben, amelyek miatt milliók dokumentuma és személyes adatai kerültek nyilvánosan hozzáférhetővé, az Elastic a security-funkciókat a kérdéses elasticsearch ingyenes verziójába helyezte. Ezt pedig úgy állítják be, mint valami óriási jót, amely a nyílt forrást segíti.
Ilyen "hatékony" megoldások fényében különösen fura a blogbejegyzés második része, amiért tulajdonképpen felfigyeltünk erre a történetre. Az szóban forgó — a Kubernetes hivatalos operátoráról az Elasticsearch és a Kibana számára.
A fejlesztők meglehetősen komoly arccal azt állítják, hogy a security-funkciók ingyenes alapcsomagba való kiemelésével az adminisztrátorok terheit csökkenteni fogják. Valójában minden rendben van.
"Garantálhatjuk, hogy minden ECK által futtatott és kezelt klaszter alapértelmezés szerint védve lesz az indítás pillanatától, anélkül, hogy további terheket róna az adminisztrátorokra" - olvasható a hivatalos blogban.
A kezdeti fejlesztők által elhanyagolt és nem igazán támogatott megoldás, amely az utolsó évben mindenki céltáblájává vált, hogyan biztosítja a felhasználók biztonságát, a fejlesztők hallgatnak.
Forrás: habr.com
