Niedawno na blogu Elastic , w którym informuje się, że główne funkcje bezpieczeństwa Elasticsearch, wprowadzone do przestrzeni open source ponad rok temu, są teraz bezpłatne dla użytkowników.
W oficjalnym wpisie blogowym znajdują się "właściwe" stwierdzenia, że open source powinien być bezpłatny, a właściciele projektu budują swój biznes na innych dodatkowych funkcjach, które oferują w rozwiązaniach dla przedsiębiorstw. Teraz do podstawowych wydań wersji 6.8.0 i 7.1.0 włączono następujące funkcje bezpieczeństwa, które wcześniej były dostępne tylko w ramach subskrypcji gold:
- TLS dla szyfrowanej komunikacji.
- Plik i native realm do tworzenia i zarządzania rekordami użytkowników.
- Zarządzanie dostępem użytkowników do API i klastra na podstawie ról; dozwolony jest dostęp wieloosobowy do Kibany z użyciem Kibana Spaces.
Jednak przeniesienie funkcji bezpieczeństwa do sekcji bezpłatnej nie jest oznaką wspaniałomyślności, lecz próbą stworzenia dystansu między produktem komercyjnym a jego głównymi problemami.
A te problemy są poważne.
Zapytanie „Elastic Leaked” zwraca w Google 13,3 miliona wyników wyszukiwania. Imponujące, prawda? Po wypuszczeniu funkcji bezpieczeństwa projektu do open source, co kiedyś wydawało się dobrym pomysłem, Elastic napotkał poważne problemy z wyciekami danych. W praktyce podstawowa wersja zamieniła się w sitko, ponieważ nikt na naprawdę nie wsparł tych funkcji bezpieczeństwa.
Jednym z najsłynniejszych przypadków wycieku danych z serwera elastic był przypadek utraty 57 milionów danych obywateli USA, o czym w grudniu 2018 roku (później okazało się, że tak naprawdę wyciekło 82 miliony rekordów). Wtedy, w grudniu 2018 roku, z powodu problemów z bezpieczeństwem w Brazylii skradziono dane 32 milionów osób. W marcu 2019 roku z innego serwera elastic wyciekło "zaledwie" 250 000 poufnych dokumentów, w tym również o charakterze prawnym. I to tylko pierwsza strona wyszukiwania dla wspomnianego przez nas zapytania.
W rzeczywistości włamania trwają do dziś i zaczęły się niedługo po usunięciu z obiegu funkcji bezpieczeństwa przez samych deweloperów oraz ich przeniesieniu do otwartego kodu źródłowego.
Czytelnik może zauważyć: „No i co? No mają problemy z bezpieczeństwem, a kto ich nie ma?”
A teraz uwaga.
Kwestią jest to, że do tego poniedziałku Elastic z czystym sumieniem pobierała od klientów pieniądze za sitko nazwane funkcjami bezpieczeństwa, które sama wprowadziła do open source jeszcze w lutym 2018 roku, więc około 15 miesięcy temu. Nie ponosząc żadnych znaczących kosztów związanych z utrzymaniem tych funkcji, firma regularnie pobierała za nie opłaty od subskrybentów gold i premium z segmentu enterprise.
W pewnym momencie problemy z bezpieczeństwem stały się dla firmy na tyle toksyczne, a roszczenia ze strony klientów — na tyle groźne, że chciwość ustąpiła drugorzędnej roli. Jednak zamiast wznowić rozwój i "załatać" luki w swoim projekcie, przez które do ogólnego dostępu trafiły miliony dokumentów i danych osobowych zwykłych ludzi, Elastic wyrzuciła funkcje bezpieczeństwa do bezpłatnej wersji elasticsearch. I przedstawia to jako wielkie dobro i wsparcie dla open source.
W świetle takich "efektywnych" rozwiązań niezwykle dziwnie wygląda druga część wpisu na blogu, z powodu której zwróciliśmy uwagę na tę historię. Mowa jest — oficjalnego operatora Kubernetes dla Elasticsearch i Kibana.
Deweloperzy z całkiem poważnymi minami mówią, że z powodu przeniesienia funkcji bezpieczeństwa do podstawowej bezpłatnej wersji elasticsearch obciążenie administratorów użytkowników tych rozwiązań zostanie zmniejszone. A w ogóle, wszystko jest świetnie.
"Gwarantujemy, że wszystkie klastry uruchamiane i zarządzane przez ECK będą chronione domyślnie od momentu uruchomienia, bez dodatkowego obciążenia dla administratorów," mówi się w oficjalnym blogu.
Jako porzucone i właściwie nieobsługiwane przez początkowych deweloperów rozwiązanie, które w ciągu ostatniego roku stało się wszechobecnym chłopcem do bicia, zapewni użytkownikom bezpieczeństwo, deweloperzy milczą.
Źródło: habr.com
