Jak przenieść się do chmury – bezpieczeństwo środowiska wirtualnego
Przeniesienie się do chmury w wielu przypadkach oznacza wykorzystanie w znaczącym stopniu mechanizmów wirtualizacji. Warto znać ich charakterystykę oraz możliwe zagrożenia z nimi związane, by odpowiednio obronić swoje zasoby.
Koncepcja wirtualizacji miała swój początek w 1960 roku wraz z rozwojem IBM System/360 model 67. W ostatniej dekadzie stała się fundamentem w rozwoju usług chmurowych. Oprócz niewątpliwych korzyści generuje też ryzyka, jak każda technologia. W dzisiejszym artykule omówimy, jakie są zagrożenia i najlepsze praktyki w kontekście bezpieczeństwa środowiska wirtualnego w chmurze. Zaczniemy od zagrożeń – a na końcu znajdziecie przegląd technik zabezpieczeń.
Warto jednocześnie zauważyć, że dbanie o bezpieczeństwo środowisk wirtualizacyjnych często jest skomplikowanym zadaniem – mnogość technologii i stopień złożoności infrastruktury nie ułatwia aktualizacji oprogramowania i prawidłowej jego konfiguracji. Tym bardziej warto w tym zakresie zaufać doświadczonym dostawcom tego rodzaju rozwiązań, którzy potrafią sprostać temu zadaniu.
Cykl artykułów
Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce. Przed nami jeszcze pięć artykułów i kilka webinarów, a w poprzednich artykułach i webinarach poruszone zostały zagadnienia:
-
- architektura modelu cloud computingu wg NIST SP 800-145,
- ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance,
- standardy bezpieczeństwa, jakie powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia,
- zarządzanie tożsamością w chmurze i standardy SAML, OpenID, OAuth,
- wdrożenie i zarządzanie uprawnieniami w chmurze,
- przygotowania do wielkiej awarii,
- bezpieczeństwo centrum danych.
Koncepcje wirtualizacji
Na początek kilka definicji i pojęć w celu wyjaśnienia czasami subtelnych różnic pomiędzy koncepcjami wirtualizacji. Generalnym założeniem wirtualizacji jest umożliwienie różnym użytkownikom zarządzania i współdzielenia fizycznych zasobów sprzętowych poprzez zmultiplikowane środowiska, które są od siebie logicznie wyizolowane.
Źródło: Ibm.com
Hipernadzorca (hypervisor) – komponent, który pośredniczy w przekazywaniu żądań między maszynami wirtualnymi a sprzętem w celu uzyskania zasobów (np. moc obliczeniowa, pamięć, przestrzeń dyskowa, interfejsy sieciowe).
- Hipernadzorca typu 1 (natywny, bare metal) – aplikacja uruchamiana bezpośrednio na poziomie sprzętu. Kontroluje i monitoruje uruchomione systemy operacyjne Gości działające na poziomie wyżej. Zazwyczaj jeden z systemów jest uprzywilejowany i służy jako domena zarządzająca pozostałymi systemami Guest. Sam monitor (VMM) działa w trybie Ring 0 (opis pierścieni poniżej), podczas gdy systemy Guest działają w przestrzeni Ring 1, a aplikacje standardowo w trybie Ring 3. Przykładami implementacji tego typu hypervizorów są: Oracle VM, Microsoft Hyper-V, VMWare ESXi, Xen.
- Hipernadzorca typu 2 (hostowany) – hipernadzorca tego typu działa jako program uruchomiony na danym systemie operacyjnym gospodarza. W tym przypadku zwirtualizowane systemy działają dwa poziomy ponad sprzętem. Przykładami są VMware Workstation, VMware Server, Oracle VirtualBox.
VMM (virtual machine monitor, virtual machine manager) – pojęcie często używane zamiennie z hypervisorem. Jest to komponent hypervisora odpowiedzialny za tworzenie maszyn wirtualnych i wsparcie dzielenia zasobów pomiędzy nimi.
Maszyna wirtualna, gość (VM, guest machine) – instancja wirtualnego środowiska z systemem operacyjnym i aplikacjami, wykorzystująca zasoby sprzętowe maszyny fizycznej (host machine) dostarczone za pośrednictwem VMM. Specjalnym rodzajem wirtualnej maszyny, w szczególności wykorzystywanym w chmurze, jest kontener, gdzie jądro systemu operacyjnego umożliwia tworzenie wielu oddzielonych od siebie instancji.
Gospodarz (host machine, gospodarz) – maszyna fizyczna z systemem operacyjnym, która jest gospodarzem dla środowiska wirtualnego. Zarządza bezpośrednio fizycznymi zasobami sprzętowymi.
Serwer zarządzający (management server) – platforma wirtualizacji złożona z zestawu komponentów, umożliwiająca m.in. bezpośrednie zarządzanie maszynami wirtualnymi, przydzielanie zasobów itd. Przykładem serwera zarządzającego jest VMware vSphere lub XEN XenCenter.
Konsola zarządzająca (management console) – komponent umożliwiający dostęp do interfejsu zarządzającego do konfigurowania i zarządzania maszynami wirtualnymi.
Komponenty sieciowe – umożliwiają tworzenie wirtualnych sieci, w których wirtualne urządzenia (np. przełączniki, routery) są kontrolowane przez oprogramowanie, a protokoły sieciowe są symulowane jako fizyczne.
Wirtualny storage – komponenty umożliwiające zasymulowanie fizycznej przestrzeni składowania, która może być dostępna przez sieć lub bezpośrednie połączenie.
Źródło: Security aspects of virtualization, ENISA
Uprzywilejowane pierścienie (protection rings) – architektura x86 wspiera cztery poziomy uprzywilejowanych pierścieni. Pierścień 0 (Ring 0) jest najwyższym poziomem uprzywilejowania i umożliwia bezpośredni dostęp do sprzętu (kernel mode) . Ring 1 i 2 są praktycznie nieużywane (wsteczna kompatybilność, portowanie kodu). Ring 3 posiada najmniejsze uprawnienia dla aplikacji.
Używane technologie
Technologie wirtualizacji można podzielić na kilka zasadniczych rodzajów. Każdy rodzaj wirtualizacji prezentuje nieco odmienne podejście do tematu oraz są związane z nim różne rodzaje podatności.
a) Pełna wirtualizacja
Może być realizowana zarówno za pomocą hypervisora typu 1, jak i 2. W przypadku pełnej wirtualizacji emulowany jest cały wirtualny komputer oraz wszystkie urządzenia. VMM jest uruchamiany na poziomie Ring 0, a uruchamianie wszystkich instrukcji gościa odbywa się na poziomie wyższym. System operacyjny gościa jest odizolowany od sprzętu i nie ma „świadomości”, że uruchomiony jest w środowisku wirtualnym. Technologie pełnej wirtualizacji umożliwiają zasadniczo uruchomienie dowolnego systemu operacyjnego w maszynie wirtualnej i dostarczają największy poziom izolacji i bezpieczeństwa. Niestety konieczność emulacji każdego urządzenia znacznie obciąża procesor fizycznej maszyny. Przykładami rozwiązań są VirtualBox, Virtual PC, VMware, Xen.
b) Parawirtualizacja
Parawirtualizacja wykorzystuje hypervisor typu 1, VMM działa bezpośrednio na sprzęcie. Jeden z wirtualizowanych systemów jest uprzywilejowany i pełni rolę zarządzającą. Podejście umożliwiające rozwiązanie problemu dostępu do określonych rejestrów procesora jednocześnie przez wiele systemów operacyjnych. Wywołania zwane hypercalls, które symulują wywołania systemowe, mogą być wykonywane przez zmodyfikowane systemy operacyjne gościa i odwoływać się do usług hypervisora. Tryb ten zapewnia dobrą wydajność wirtualnego środowiska, ponieważ usunięta została dodatkowa warstwa emulacji programowej. Rozwiązania: VirtualBox, Xen PV, KVM/QEMU, Parallels, Microsoft Hyper-V.
c) Wirtualizacja sprzętowa, pełna wirtualizacja ze wsparciem sprzętowym (HVM, hardware-assisted virtualization)
Jest to odmiana wirtualizacji pełnej, która korzysta ze sprzętowych rozszerzeń wirtualizacji architektury x86 – dla procesorów Intel (VT-x), dla procesorów AMD (AMD-V). Schemat wykorzystania pierścieni nieco się zmienia. Rozszerzenia sprzętowe dostarczają również dodatkowe tryby: root mode oraz non root mode. Każdy z tych trybów zawiera niezależne tryby Ring 0-3. Hypervisor typu 1 działa w trybie root mode, mając pełny dostęp do prawdziwego sprzętu, podczas gdy niezmodyfikowany guest działa w standardowych dla siebie trybach Ring 0-3 w trybie non root mode, a jego dostęp do sprzętu jest w pełni kontrolowany przez hypervisora. Obecnie większość dostępnych na rynku procesorów spełnia te wymagania. Przykłady rozwiązań: KVM/QEMU, Xen HVM, VMware ESXi, vSphere, MS Hyper-V.
d) Wirtualizacja na poziomie systemu operacyjnego (Operating System-Based Virtualization)
W tym rodzaju wirtualizacji mamy do czynienia z uruchamianiem tego samego (lub zbliżonego) systemu operacyjnego w tak zwanym kontenerze. Kontener izoluje określony kod, aplikację lub proces. Kontenery są uruchamiane na podbudowie systemu operacyjnego, więc nie wymagają uruchamiania systemu operacyjnego za każdym razem, gdy są tworzone lub uruchamiane. Kontener zawiera aplikacje, pliki użytkownika oraz dane środowiskowe. Każdy kontener jest budowany z obrazu, który przekazuje informacje, co dany kontener zawiera, jakie procesy są uruchamiane wraz z uruchomieniem kontenera, a także zawiera dane konfiguracyjne i środowiskowe. W tym podejściu, jeśli atakujący dokona wstrzyknięcia skryptu umożliwiającego przejęcie kontroli nad systemem operacyjnym gospodarza, przejmie kontrolę nad istniejącymi lub utworzonymi w przyszłości maszynami wirtualnymi. Przykładami tego rodzaju wirtualizacji są Docker, Virtuozzo, OpenVZ,, Solaris Containers.
e) Wirtualizacja na poziomie aplikacji (Application-based virtualization)
Zakłada emulację osobnych wirtualnych maszyn zawierających swój własny system operacyjny i powiązane aplikacje. Środowiska składają się z wielu komponentów, takich jak interpretery, kompilatory, weryfikator kodu bajtowego i bibliotek. Przykładami rozwiązań wspierających wirtualizację na poziomie aplikacyjnymi są Java VM, Microsoft.NET, Perl, Python, Ruby.
Źródło: Security aspects of virtualization, ENISA
Podatności
Do klasyfikacji i posługiwania się przykładami słabości związanych z poszczególnymi komponentami środowisk wirtualnych posłużę się bazą CWE (Common Weakness Enumeration) oraz słownikiem CVE (Common Vulnerability Exposure).
Mapowanie pomiędzy słabościami wirtualizacji i CWE – Security aspects of virtualization, ENISA
Systemy operacyjne gości (Guest OS) i gospodarzy (Host OS)
Obie grupy systemów posiadają krytyczne podatności związane z modelem wirtualizacji opartym o system operacyjny oraz możliwością uzyskania dostępu na poziomie administratorskim. Dodatkowo można w nich znaleźć wiele podatności związanych z lukami w aplikacjach.
Wykorzystanie słabości w systemach operacyjnych gości i gospodarzy stanowi punkt wyjścia dla wielu dalszych ataków wycelowanych w maszyny wirtualne (direct attack), hypervisora, zasoby sprzętowe czy architekturę gospodarza (side-channel attack), np. ostatnia luka wykryta w procesach intela. Poniżej kilka przykładów słabości systemów operacyjnych gości i gospodarzy oraz związanych z nimi konsekwencji.
Przykładami ataków wykorzystujących niewłaściwą konfigurację lub walidację wejść (improper input validation) są side channel attacks z jednej maszyny wirtualnej na drugą i eskalacja uprawnień w systemach operacyjnych gościa. Pierwszy może prowadzić do ujawnienia istniejącej aplikacji lub plików na innej maszynie wirtualnej. Ciekawy przykład ataku z zastosowaniem deduplikacji pamięci jest opisany w tym artykule. Drugi wykorzystuje podatności (np. CVE-2015-6933) do podniesienia uprawnień na Guest OS.
Kolejnym przykładem jest atak za pośrednictwem luki w systemie operacyjnym Windows 10 umożliwiającej uruchomienie aplikacji w celu ominięcia zabezpieczeń hypervisora Hyper-V (HVCI).
Kontenery
Kontenery różnią się w swym działaniu od systemów operacyjnych gościa oraz maszyn wirtualnych, ale posiadają wspólne słabości związane z kontrolą dostępu czy eskalacją uprawnień. W szczególności podatności mogą prowadzić do tzw. ucieczki z maszyny wirtualnej (VM Escape) i uzyskania dostępu do warstwy wyższej (hypervisor, OS host), ataków na aplikacje uruchomione na VM, atakach na całe kontenery czy architekturę gospodarza. W ostatnich latach pojawiło się kilkanaście podatności pozwalających na „wyskoczenie” z maszyny wirtualnej, takich jak np. Directory Traversal we współdzielonych katalogach Vmware czy możliwość zdalnego wykonania kodu w Hyper-V. Najbardziej znanym i najlepiej opisanym przykładem był atak nazwany VENOM (Virtualized Environment Neglected Operations Manipulation) dotyczący środowisk zwirtualizowanych Xen, KVM i QEMU. Był on możliwy poprzez wykorzystanie błędu typu buffer overflow znajdujący się w wirtualnym kontrolerze dyskietek wykorzystywanym we wspomnianych wyżej platformach wirtualizacyjnych.
Kolejną grupa komponentów posiadającą wspólne podatności są hypervisory/VMM/Serwery i konsole zarządzające. Z punktu widzenia bezpieczeństwa najlepiej by było, gdyby hypervisor był możliwie jak najprostszym systemem posiadającym podstawową funkcjonalność w celu zminimalizowania możliwości ataku. Jednakże jest to bardzo skomplikowany i rozbudowany system z wieloma podatnościami stanowiącymi łakomy kąsek dla atakujących, związanymi m.in. z izolacją maszyn wirtualnych, kanałami do komunikacji z VM, dodatkowymi API. Żeby móc je wyeksploatować do ataku często wykorzystywane są słabości innych komponentów, najczęściej na poziomie gościa i gospodarza. Są to zazwyczaj klasyczne luki w oprogramowaniu wywołań (hypercalls), metod uwierzytelniania czy autoryzacji. Aby wykorzystać niektóre podatności, musi wystąpić odpowiedni kontekst środowiskowy. Dla przykładu, jeśli fizyczne jednostki CPU są wysycone, pewne błędy w oprogramowaniu wywołań mogą być wykorzystane do przepełnienia bufora (np. luka w XEN związana ze słabością Numeric Errors).
Hypervisory posiadają też wiele podatności związanych z możliwością wstrzyknięcia, takich jak VMM oriented-injection, OS-command inection czy software library injection. Jedną z metod ataków jest tzw. hyperjacking polegający na instalacji oprogramowania udającego nadzorcę. System operacyjny jest nieświadomy kompromitacji na niższym poziomie, ponieważ fałszywy hypervisor działa w trybie stealth i tradycyjne zabezpieczenia nie wykrywają zagrożenia. Atakujący może umieścić podstawionego nadzorcę nad oryginalnym hypevisorem i w ten sposób przejąć nad nim kontrolę. Choć ataki tego typu zakończone powodzeniem nie zostały jeszcze odnotowane w realnym środowisku, aby się przed nimi uchronić, należy ograniczyć ruch do narzędzi zarządzania bezpieczeństwem w hypervisorze oraz zablokować dostęp z konta gościa.
Nadzorcy mają wiele funkcji ułatwiających zarządzanie i udostępnianie zasobów VM, takich jak migracja i klonowanie, powodujących wiele podatności związanych z prostym kopiowaniem i wklejaniem obrazów maszyn wirtualnych. Jednym z przykładów ataków wykorzystujących tego typu słabości jest Cloudburst VM Escape. Używa on luki w VMWare Workstation działającej w połączeniu z Cloudburst, oprogramowaniem IBM służącym dostawcom chmurowym do zarządzania usługami. Podatność umożliwia atakującemu uruchomienie kodu na wirtualnej maszynie, który powoduje, że system operacyjny gościa może oddziaływać bezpośrednio na nadzorcę i uzyskać dostęp do hosta i innych uruchomionych na nim VM-ów.
Hypervisory są narażone również na ataki na zwirtualizowane zasoby sprzętowe. Niektóre z nich wykorzystują rootkity ukryte w oprogramowaniu sprzętowym (firmware rootkits), które mogą tworzyć tylne drzwi (backdoors).
Sieci wirtualne (virtual networks) łączą maszyny wirtualne w podobny sposób jak fizyczne. Posiadają też podobne do nich podatności, jak zatrucie tablic ARP. Zarządzanie siecią jest emulowane poprzez oprogramowanie, więc posiada też luki typowe dla software’u oraz programowalnych sieci komputerowych (Software Defined Networks, SDN). Poniżej kilka przykładów podatności sieci wirtualnych.
Podatność CVE-2013-6398 związana z luką w wirtualnym ruterze Apache CloudStack umożliwiała ominięcie ograniczeń dla źródeł po jego restarcie.
Szereg krytycznych luk w Openswitch umożliwiających przepełnienie bufora
Wirtualna przestrzeń (virtual storage)
Problemy w architekturze wirtualnej przestrzeni mogą wynikać z łączenia technologii różnych dostawców np. integracja IBM Tivoli Storage Manager for Virtual Environments z VMware vSphere GUI skutkowała pojawieniem się podatności:
- Cross-site scripting (XSS) spowodowany niewłaściwą walidacją wejść. Podatność może być wykorzystana do wstrzyknięcia skryptu lub kodu HTML poprzez odpowiednio spreparowany URL i spowodować wykradzenie ciasteczek zawierających dane uwierzytelniające.
- Luka umożliwiająca przywrócenie maszyn wirtualnych i w konsekwencji uzyskanie dostępu do danych wrażliwych
Podatności mogą również pojawiać się w wyniku niewłaściwego zarządzania danymi uwierzytelniającymi czy nieodpowiedniej kontroli dostępu. Przykładem jest luka w HP StoreOnce Virtual Storage Appliance umożliwiająca zdalny, nieautoryzowany dostęp do storage’u.
Jak się zabezpieczyć
Na koniec chciałbym przedstawić kilka rekomendowanych praktyk (ISACA, NIST, ISC², Cloud security Alliance) oraz narzędzi, które pomogą zwiększyć poziom bezpieczeństwa poszczególnych komponentów środowiska wirtualnego i tym samym usług chmurowych, z których korzystamy. Wybierając usługę, upewnijmy się, czy dostawca umożliwia korzystanie z nich bądź czy będziemy mogli samodzielnie je zastosować. Głównie dotyczą one usług IaaS w modelu chmury publicznej. Szczegółowy sposób wdrożenia, niektórych z wymienionych poniżej praktyk oraz innych, które powinny być stosowane przez dostawcę (m.in. z zakresu bezpieczeństwa fizycznego, środowiskowe, GRC), została szczegółowo opisana w artykułach i webinarach poświęconych bezpieczeństwu chmury.
| Komponent | Słabość / Możliwy atak | Praktyka |
| Guest/Host OS/kontenery |
|
|
| Hypervisor/VMM |
|
Hypervisor typu 1 ze wsparciem sprzętowym:
|
| Sieci wirtualne | podatności jak w fizycznych sieciach umożliwiających podsłuchiwanie, przejęcie czy uniemożliwienie transmisji |
|
| Wirtualny storage |
|
|
Z pomocą powyższej tabelki możecie przepytać dostawcę swojej usługi chmurowej (lub kilku), by porównać, na ile profesjonalnie podchodzą do zapewnienia bezpieczeństwa infrastruktury.
Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.
Podobne wpisy
- Zapraszamy na studia podyplomowe z cyberbezpieczeństwa w Krakowie
- Dlaczego warto, by system klasy PAM zastąpił w firmie managery haseł
- Product Manager Senhasegura, Kamil Budak, gościem RK o 21:00
- Zarządzaj dostępem zdalnym z darmowym narzędziem Fudo One
- Podstawy Bezpieczeństwa: Jak zadbać o bezpieczeństwo i prywatność na Discordzie
Punkt 69. Nie przenosić się do chmury.
Chmura, to piękna, wspaniała koncepcja zasobów rozproszonych. Serio. Normalnie, bajka. Tylko, że są dwa, główne problemy, które dostrzega KAŻDY choć trochę znający się na analizie kosztów i procesów firmy:
1. Rozwiązania chmurowe są i zawsze będą cholernie drogie, bo drogie w nich jest wszystko – począwszy od infrastruktury, przez niezbędność posiadania ludzi, którzy utrzymają infrastrukturę, drogi jest software tworzący chmurę i drogie jest utrzymywanie ludzi, którzy utrzymują ten software. To nie jest mechanika klasyczna, gdzie kupowało się dedyka za 50k rocznie i wystarczył jedynie jeden koleś, który ustawi IP serwera i skonfiguruje połączenie. Nie, tu musisz mieć sztab ludzi, w każdym jednym miejscu, o analizie całego systemu softwarowo i hardwarowo nie wspominając. Nie dość tego, chmura generuje znaczne starty, to nie jest dedyk, gdzie problem izoluje się na podstawie jednej maszyny, to jest sieć rozproszona na tyle, że wykrycie jednego błędu na pojedynczej maszynie WYMUSZA analizę problemu na każdej maszynie w zespole, bo odpowiednia kontrola błędów i izolacja jest niemożliwa.
Wynik? Rozwiązania chmurowe oferujące takie same możliwości co dedyki, są średnio 3 razy droższe, lepiej, chmury oferujące takie same możliwości jak klasyczne VPSy są średnio 50-150% droższe. I to nie jest tak, że chmura w przedsiębiorstwie „zmniejsza” konieczność zatrudnienia ludzi obsługujących serwery. Nie, masz dokładnie taki sam niezbędny zespół administracyjny i większe koszty samych serwerów.
Chmury są fajne, jak są minimalistyczne, prowadzi się bloga czy coś i potrzebuje małej, niezawodnej dla użytkownika maszynki, płaconej za „użycie”. Ale jak się prowadzi działalność opartą o witryny internetowe? Analiza MOICH kosztów wskazała, że taniej mi zatrudnić 6 dodatkowych ludzi i dedyka, niż kupić chmurkę dającą zbliżone możliwości.
2. Straty i generowanie dodatkowych kosztów. Chmury nadają się do obliczeń. Ale do analizy, kontroli i wymianie danych? To już totalna średniawka. Wymuszają tworzenie potężnych klastrów macierzy, gdzie kontrola błędów… inaczej, błędy się nie dość że łatwo powielają, to jeszcze MUSZĄ robić backupy, żeby w razie godziny W dane odzyskać. Infrastruktura dyskowa leci w nieskończoność i jak w każdym systemie silnie rozproszonym, nie da się tego uniknąć. Dlatego np. jako bank, korzystając z usługi chmurowej dodatkowo bym się zdecydował na ubezpieczenie, tak na wszelki wypadek. Problem nie ogranicza się jedynie do danych, w zasadzie, do wszystkiego, nawet adresacja pamięci jest problemem.
w zasadzie, zadeklarowałbym jeszcze jeden problem, niemożliwy do rozwiązania w systemie silnie rozproszonym:
3. Kolejkowanie zadań wymaga dodatkowych zasobów. Tak, żeby realizować w chmurze 3 procesory 2Ghz, musisz mieć fizycznie 2 procesory 2Ghz i 1 3Ghz, żeby zrealizować 14GB pamięci, musisz mieć fizycznie 16GB pamięci. Nie da się tego przeskoczyć, bo sam konieczny ruch wymiany danych, kolejkowania danych, kolejkowania zapytań, procesów, nawet jak korzystają z najlepszych obecnie algorytmów – zżerają dodatkowe zasoby i to w cale nie małe, bo nie realizują tego na szybkim stosie, tylko na kolejkach priorytetowych, a raczej na grupach kolejek priorytetowych. Więcej zasobów? = Więcej kosztów. Czemu? Pomijając nawet, że musisz mieć „silniejsze” podzespoły, to sam wzrost obciążeń energetycznych już generuje spore koszty.
Chmura to nic innego, jak marzenie any-Neumannów o systemach wieloprocesorowych MIMD. Nie udało się wtedy, bo brakło mocy, teraz się udaje, bo mamy sporo mocy, tylko po co ją marnować…
Kiedy aruba da platnosc SMS… to wtedy sie tam zagoszcze. Chwalicie sobie ten hosting?
Aruba jest OK ghyby nie to ze reinstall OS sie placi!
To nie jest VPS gdzie mozesz sobie robic reinstall do woli, tutaj za kazdym razem jak jest reinstall placi sie jak za nowy serwer. ARUBA: NIE POBIERAJCIE KASY ZA REINSTALL!!!
Płatności sms to domena kiepskich hostingów za 5zł używanych często do dystrybucji materiałów niekoniecznie zdrowych dla komputera ;) Do tego płatności sms są obarczone bardzo wysoką prowizją (kredytówki czy inne płatności online ok. 1.5%-2% wartości transakcji, sms ok. 50% wartości transakcji), więc jest to po prostu nieopłacalne.
Jozek,
Nierozumiesz chmury bo patrzysz z perspectywy starej architektury na przyszlosc. Ja w chmurze jest szybszy od ciebie i dlatego zabieram ci biznez.
Dzis na swiecie niekogo nie obchodzi chmura lub infrastractura tylko tranformacja do niej i applikacje. Chmura dac ci AI, IOT, BA – kogo obchodza sieci, IP, servery Ghz etc? Chumara roznie i maleje sama. To prawda ze jezeli wezmiesz stara architecture i przyniesiesz ja do nowerj to wszystko bedzie drozesz. Ale jezeli transformujesz swoj biznez do chmury dobrze to bedzie taniej – robie to od lat poza polska.
Postaraj sie zrozumiec przyszlosci bo biznes to nie tylko ilosc pieniedzy wynady na IT. Technologia to byc albo nie byc biznesu wiec szybsze i madrzejsze biznesy wygrywaja!
regards
M
Czekaj czekaj, chcesz mi powiedzieć, że ty, bobek, przedsiębiorca zewnątrzpolski rozwiązałeś problem szeregowania zadań systemu rozproszonego, rozwiązałeś problem przydzielania procesów w takty zegara procesora, znalazłeś sposób na problem arbitrażowy magistrali danych, wykorzystałeś swoją wiedzę do naprawienia problemu kolejkowego przetwarzania danych, znalazłeś sposób lepszy niż system plików, zamieniłeś jak Jezus asynchronikę w synchronikę, znalazłeś sposób by wirtualizacja na wirtualizacji systemu operacyjnego zajmowała tyle samo zasobów co system operacyjny i rozwiązałeś TYSIĄCE innych problemów, metodyk, protokołów i nawet nie chce mi się tego wymieniać. Nie? To jak ty śmiesz do mnie mówić, że jest szybciej? :D
Chmura jest dobra do PEWNYCH zastosowań. Tak jak mówiłem, do obliczeń (zresztą, sam to wymieniłeś: Chmura dac ci AI (artificial intelligence), IOT (internet of things), BA (a to to nie wiem co to jest, chyba chodziło ci o BD – big data, a nie o business analysis). Chmura jest dobra do zastosowań, w których konieczna jest duża moc obliczeniowa i dane są SILNIE rozproszone, tak jak mówiłem. Ale jak ja, nazywam się Zdzisław, potrzebuję postawić stronę sklepu internetowego, to paaaaaanie chmura? Ne ne.
Poza tym… cholera, jak miałbym się skupić, ale tak na prawdę skupić, to AI odpalałbym na jakimś extragridzie, dalej na fizycznych serwerach. Zresztą zrobiłem 10 minutowy research i dalej każda uczelnia/naukowcy, którzy się zajmują zagadnieniem dalej robią to na swoich serwerowniach. Big Data, jak miałbym wysilić się o 9 rano jeszcze bardziej, to Big Data to nic innego jak używanie algorytmów genetycznych albo sieci neuronowych do wyciągania wniosków z dostarczonych danych. Ciekaw jestem, jak ktoś chce mi udowodnić, że symulacja systemowa będzie szybsza przy takich samych zasobach hardware’owych :D
OK ja rozumiem twoją perspektywę, serio. Kupujesz 100 maszynek używanych po przecenie na ebayu, stawiasz blaszaka ocieplanego wełną i styropianem, wsadzasz tam 20 klimatyzatorów, podpinasz się kablem do lokalnego węzła wymiany danych z łączem 1Tbs, ściągasz gotowce z githuba, uruchamiasz, konfigurujesz i faktycznie masz najtańszą chmurę na świecie. Nawet lepiej, bo wystarczy znalezienie jednego jelenia, który od ciebie kupi serwery. Chmura jest tak droga, że odpowiednio duży jeden jeleń może ci pokryć wszystkie koszty utrzymania takiej „profesjonalnej” serwerowni, a przy drugim jeleniu już zarabiasz.
Całkowicie rozumiem i szanuję taką koncepcję biznesową, biznes to biznes, ma przynosić hajs, a że obecnie jest hype na chmurę i na blockchaina, to prosta sprawa, na czym zarobić najłatwiej. Tylko ja, uwzględniam PROFESJONALNE rozwiązania chmurowe, takie, jakie np. tworzy Małomiękki. Wiesz ile Małomiękki zatrudnia ludzi, w swoim dziale „chmurowym”? Ponad 2000. DWA TYSIĄCE. Dla takiej samej infrastruktury ale nie chmurowej potrzebowaliby jakieś 100-150 osób, ale i tak się im to opłaca, bo tak jak mówiłem – chmury są 3x droższe, a swojego OneDriva mieli jeszcze zanim chmury opracowano.
Święta prawda. Od pewnego pułapu chmury są nieopłacalne i za taką samą cenę dedyk zrobi wszystko więcej i lepiej niż hiper ultra AI chmura od Google’a czy Amazona. Obecnie mamy hype na chmurę i w związku z nią hype na Artificial Intelligence, Neural Networks, a kiedyś na Big Data i jak to bywa w informatyce moda przewyższa zdrowy rozsądek i (o zgrozo) wiedzę.
Najsmutniejsze, że ludzie z tego AI nie korzystają. Przeczytałem kilkadziesiąt opracowań i wpisów pt. „jak AI pomaga twojemu biznesowi!” i goście nie ogarniają, do czego AI może służyć i do czego faktycznie ją można wykorzystać.
Obecnie ci wszyscy specjaliści mylą AI ze zwykłą predykcję danych opartą na sieć neuronową albo algorytmach genetycznych. Nawet nie ogarniają, że TABUsearch, to wymysł starszy od macierzy RAID i prowadzi szybciej do tych samych wyników przy danych, którymi ci specjaliści chcą operować.
AI to nie jest system predykcyjny, AI nawet jest gówniane jeżeli chodzi o zastosowania predykcyjne, bo AI to tylko dostępne operacje i jakieś dane. AI nie koniecznie zwraca wynik, ba, nawet ten wynik nie musi spełniać wymagań, ani nawet nie musi być konkretny.
Sieć neuronowa, to nie jest AI.
A Podstawy pod Big Data? Błagam was, sieć neuronowa (powstanie pomysłu i proof of work = 1943, pierwsze zastosowanie identyczne jak w czasach dzisiejszych – 1965), algorytmy predykcji danych wymyślone zostały gdzieś w okolicach pierwszej wojny światowej, jak do masowego użycia weszły algorytmy szyfrujące. Jak jakaś firma zatrudniała dobrych pracowników i umiała odseparować tych na prawdę wartościowych od bezużytecznych github-kopiuj/wklej, to miała systemy „Big Data” zanim ktoś jeszcze w ogóle wpadł na pomysł, by to tak nazywać.
IoT? Nie lubię tego określenia, bo to w zasadzie nie internet. Nazwałbym to „SNMP Web”. Urządzenia, które mają swoje karty sieciowe i MAC adresy, IP i całą inną gównianiznę, która też jest wymysłem, nad którym cywilizacja powinna już przeskoczyć, w zasadzie nie robią nic innego, jak wszystkie swoje operacje pakują w ramkę, ramkę do interface’u GUI i wygłaszają „HEEEEJ! Tu jestem! Wejdź i zobacz, czy ci w lodówce brakuje śmietaaaanyyy!”, jak każde inne urządzenie, które ma kartę SNMP. Różnica polega na tym, że SNMP i jego obsługa JEST w jakiś sposób zabezpieczone, natomiast te „inteligentne” warte miliony dolarów urządzenia, to w zasadzie głównie udostępniają swoje zasoby jako zombies dla botnetów…
FYI Przez dostanie 10 lat zbudowalem 15 DC z 4000 klientami dosc duzy backbone dookola swiata z 4-5 chmurami publicznie dostepnymi dla tych klientow. Ja nie mowie k ludziach ktorzy chca stroninternetowych tylko korporacjach globalnych, Moja ewolucja przyniosla mnie tu: Dzis nie obchodzi mnie detale technologi tylko rozwiazania ktore w kilka dni lub tygodni moge polaczyc z architectura swojego biznesu aby byc szybszy lub bardziesz oplacalny. Nie jestem z Polski tazke nie wiem kto to jest Malomiekki i dlatego nie wiem jakich ludzi zatrudnia w chmurze i w jakiej generacji chmury dziala.
Obecnie staram sie pomagac w transformacji form globalnych do publicznej chmury bo… biznesu nie obchodza problemy IT tylko ich rozwiazania.
Widzisz ani ty i ja nie rozwiarzemy tych problemow opisanych przez ciebie na gorze ..ale ludzie z GCP, Azure, AWS je rozwiarza lub znajda inne alternatywne architectury.
Nie mam czasu rozmisywac sie na tem temat ale staram sie tylko poweiedziec zeby uzawaz na slowa w ktorych mowicie ze chmura jest nieoplacalna itd. Instynkt czy emocje tu nie powinny grac zanej roli bo robi sie TCO and ROI zeby to udowodnic. Jak widzicie przyznaje wam czesc prawdy bo sam fakt ze takie analyzy trzeba robic udowadnia ze czasami chmura nie jest oplacalna :)
Wiecie ze czasami przy takie analizie doradzamy ludziom zeby zostali tam gdzie sa bo ich kultura ludzka i sposob myslenia nie pozwala na transformacje!
Reasumujac, ta chmura jest szybsza pod kazdym wzgledem, jest bardziej innowacyjna (a to dopiero poczatek) i ja uwazam ze bezpieczniejsza (jezeli zrobiona poprawnie). Przyszlosc nalezy do tych ktory nie maja wszystkich odpowiedzi a zadaja dobre pytania.
Dobrze by bylo sie spotkac i pogadac o tym bo chcialbym poznac wasza perspectywe ktora jest prawdziwa w waszym srodowisku :)
Pozdrawiam!
Ehhh…
1. Małomiękki to Microsoft
2. Cieszę się, że udaje ci się biznes
3. „Widzisz ani ty i ja nie rozwiarzemy tych problemow opisanych przez ciebie na gorze ..ale ludzie z GCP, Azure, AWS je rozwiarza lub znajda inne alternatywne architectury.”
Ale do tej pory nie znaleźli, więc na czym opierasz swoje zdanie? Poza tym, nadużywasz słowa „architektura”. Architektura odnosi się głównie do rozwiązań hardwarowych albo do sposobu ich modelowania. I gwarantuje ci, że przez jeszcze co najmniej 15 lat, nikt nie odejdzie od architektury X86 czy inicjowania sieci na podstawie warstw OSI i chociażby protokołu TCP.
4. „zeby uzawaz na slowa w ktorych mowicie ze chmura jest nieoplacalna”
Nikt nigdy nie powiedział, że chmura jest nieopłacalna, gdy ROBISZ na niej biznes, czyli prowadzisz usługę chmurową. Dla providerów usługi chmurowej to góra złota. Dla klienteli, której się to chce wepchnąć już niekoniecznie.
5. „Reasumujac, ta chmura jest szybsza pod kazdym wzgledem”
Kłamstwo. Potwierdza tylko, że nie wiesz o czym mówisz, ani jak faktycznie działa chmura. To, że umiesz na usłudze zarabiać nie znaczy, że znasz tą usługę. Chmura rozwiązuje tylko i wyłącznie problem skalowania rozproszonego w sieci rozproszonej, zapewnia TYLKO liniowy przyrost mocy w stosunku do dokładanych zasobów (a liniowy, to jest w sumie – najmniejszy, aby uznać system za skalowalny). Poczytaj sobie o systemach wbudowanych, zrozumiesz, czym jest pojęcie „najszybsze”. Najszybszym rozwiązaniem było by, gdyby Chmura realizowała się bez systemu operacyjnego w języku assemblerowym :> Powodzenia Amazon!
6. „jest bardziej innowacyjna (a to dopiero poczatek)”
Innowacyjna? Ja bym powiedział, że po prostu jest na to hype. Usługi symulacji wielokomputerowej to nie jest wymysł nowy, wręcz przeciwnie, ludzie zmagali się z problemem zwielokrotnienia zasobów od początków informatyki, gdy tranzystor miał 10×10 centymetrów. Powiedziałbym, że powstało trochę nowego softwaru łatwego w implementacji dla laików.
7. „bezpieczniejsza (jezeli zrobiona poprawnie).”
Prawdę mówiąc, to kłamstwo. Chmurę realizuje się głównie softwarowo (sorry, ale te hardwarowe routery/macierze czy co tam jeszcze, to ma tyle nowoczesności chmurowej, jak tylko cenę 2x większą), a skoro software’owo, to znaczy, że na starych systemach operacyjnych i na bieżących rozwiązaniach. Nigdy system, który dokłada DODATKOWY komponent nie może być bezpieczniejszy, niż system o mniejszej liczbie komponentów. No taki jest fakt informatyki. Czym więcej komponentów = tym więcej miejsc wrażliwych.
8. „ale ludzie z GCP, Azure, AWS”
Haha tak w zasadzie to teraz nawet podejrzewam, że nie posiadasz własnych serwerowni, a jedynie usługę, która pośredniczy w kupowaniu chmury od wyżej wymienionych i dokłada sobie 5% ceny + opłatę za konsulting :>
9. „Przyszlosc nalezy do tych ktory nie maja wszystkich odpowiedzi a zadaja dobre pytania.”
To jest motto biznesu. I jest słuszne. Natomiast motto informatyki było od zawsze takie, że kto da skuteczniejsze rozwiązanie ten wygrywa. I to się raczej prędko nie zmieni, zapytaj Google. ;)