Konferencja AWS re:Invent 2019, podobnie jak jej poprzednie edycje, obfitowała  w ciekawe wykłady typu breakout sessions, których celem było przybliżenie uczestnikom wybranego zagadnienia technicznego związanego z chmurą Amazon Web Services. Jedno z takich wystąpień zainspirowało mnie do napisania kilku słów na temat bezpieczeństwa aplikacji stworzonych w modelu serverless. Zaufanie świata biznesu do tej architektury systematycznie rośnie, nie tylko wśród startupów i małych firm, ale także w dużych organizacjach. Wiele wskazuje na to, że w najbliższych latach trend ten się utrzyma i liczba produkcyjnych wdrożeń serverless będzie coraz większa. Dlatego zdecydowanie warto przyjrzeć się narzędziom, które AWS udostępnia, aby pomóc programistom, administratorom i architektom minimalizować ryzyko wycieku danych czy przejęcia kontroli nad ich oprogramowaniem.

Decydując się na wdrożenie aplikacji w modelu serverless, dzielimy odpowiedzialność za jej bezpieczeństwo z dostawcą usług chmurowych. Opisuje to tzw. model współdzielonej odpowiedzialności (ang. Shared Responsibility Model) [1]. Amazon Web Services musi zadbać o zabezpieczenie całej infrastruktury obliczeniowej i sieciowej, właściwą konfigurację systemów operacyjnych i części oprogramowania (hypervisora, firewalla, itp.), instalowanie aktualizacji i poprawek bezpieczeństwa na bieżąco, czy szyfrowanie danych i ruchu sieciowego. W gestii klienta, będącego bezpośrednim użytkownikiem usług AWS, leży natomiast implementacja swojego programu w taki sposób, aby uniemożliwić potencjalnym atakującym dostęp do poufnych zasobów czy wykonanie niepożądanych działań. Innymi słowy – klient sam odpowiada za błędy w kodzie i logice biznesowej aplikacji, a także za właściwe monitorowanie istotnych parametrów i logowanie zdarzeń.

Uwierzytelnianie użytkowników

Obecnie, niemal każda aplikacja biznesowa posiada mechanizm kontroli dostępu. Chcemy mieć pewność, że użytkownik jest rzeczywiście tym, za kogo się podaje oraz ma dostęp tylko do tych zasobów, do których mieć powinien. Najczęściej stosowaną metodą uwierzytelniania jest wykorzystanie hasła statycznego, które zwykle jest zapisane w bazie danych. Oczywiście przechowywanie haseł jako zwykły, niezaszyfrowany tekst (ang. plaintext) jest praktyką absolutnie niedopuszczalną.

Niewiele lepszym rozwiązaniem jest ich hashowanie kiepskimi funkcjami skrótu kryptograficznego, jak np. MD5 czy SHA1, które od dawna przestały być uważane za bezpieczne. Jeśli ktoś podchodzi do kwestii bezpieczeństwa poważnie, powinien skoncentrować swoją uwagę na jednym z nowoczesnych algorytmów hashujących, przykładowo Bcrypt czy PBKDF2. Posiadają one wbudowane mechanizmy key stretchingu oraz dodawania soli, dzięki czemu są w wysokim stopniu odporne na ataki siłowe (ang. brute force), słownikowe czy te z wykorzystaniem tablic tęczowych (ang. rainbow tables).

Istnieje również możliwość uwierzytelniania użytkowników bez konieczności przechowywania haseł w jakiejkolwiek bazie danych, ani nawet przesyłania ich między klientem a serwerem,  a to wszystko dzięki wykorzystaniu protokołu SRP (ang. Secure Remote Password). W dużym uproszczeniu: zamiast hasła, wymaga on przechowywania weryfikatora, czyli wartości obliczonej według wzoru v = gx mod N, gdzie g jest tzw. generatorem grupy, N – odpowiednio dużą liczbą pierwszą, a x – wartością obliczoną na podstawie nazwy użytkownika, hasła oraz soli poprzez zastosowanie jednokierunkowej funkcji skrótu.

Zadaniem stojącym przed potencjalnym atakującym, który zechce złamać protokół, jest obliczenie x, czyli znalezienie logarytmu dyskretnego. Nawet znając wartości N oraz g, jest to problem niezwykle trudny obliczeniowo (przy założeniu, że liczba N spełnia określone kryteria). Protokół SRP może zatem stanowić ciekawą, ale i wymagającą w implementacji alternatywę dla popularnego przechowywania hashy haseł w bazie danych.

Czy w takim wypadku musimy zatrudniać programistę ze znajomością arytmetyki modularnej, aby móc cieszyć się bezpiecznym procesem uwierzytelniania w naszej aplikacji? W świecie serverless – nie. Takich programistów zatrudnił już Amazon, żeby wykonali za nas całą żmudną pracę. Dlatego możemy (a nawet powinniśmy) skorzystać z usługi Amazon Cognito, która uwolni nas od odpowiedzialności za bezpieczne przechowywanie danych dostępowych użytkowników.

Dzięki bibliotekom do wielu popularnych języków programowania ułatwi również implementację logiki uwierzytelniania, zarówno z wykorzystaniem protokołu SRP, jak i bez niego. Cognito umożliwia stworzenie własnej puli użytkowników oraz integrację z zewnętrznymi dostawcami tożsamości, takimi jak Google, Facebook, Amazon, czy dowolnymi innymi, którzy wspierają protokół OpenID Connect lub SAML. Ułatwia to wdrożenie jednej z dobrej praktyk bezpieczeństwa, czyli centralizacji zarządzania tożsamością, co przekłada się na ograniczenie liczby możliwych wektorów ataku.

Z punktu widzenia aplikacji istnieje wtedy tylko jeden magazyn tożsamości, chociaż w rzeczywistości dane użytkowników mogą być przechowywane w wielu różnych miejscach. Wykorzystanie Amazon Cognito w naszej serverlessowej układance to zdecydowanie krok w dobrym kierunku, jeśli zależy nam na wysokim poziomie bezpieczeństwa.

Kontrola dostępu do REST API

Jest wysoce prawdopodobne, że Twoja aplikacja serverless wykorzystuje (lub będzie wykorzystywała) REST API do wymiany danych pomiędzy różnymi komponentami.

W chmurze AWS do tworzenia i zarządzania endpointami API istnieje dedykowana usługa  o nazwie Amazon API Gateway. Pomimo faktu, że w tym przypadku również dzielimy odpowiedzialność za bezpieczeństwo z dostawcą, należy pamiętać, że to do nas należy obowiązek zadbania o właściwą konfigurację. Jednym z kluczowych jej elementów jest tzw. authorizer, czyli mechanizm wbudowany w API Gateway, którego zadaniem jest kontrola dostępu do naszego API. Rozważmy fragment architektury prostej aplikacji, przedstawiony na poniższym diagramie.

Architecture fragment

Aplikacja kliencka wysyła żądania do jednego lub wielu endpointów REST API udostępnianych za pośrednictwem usługi Amazon API Gateway, która następnie wywołuje odpowiednie funkcje Lambda. Jeśli aplikacja posiada mechanizm uwierzytelniania, prawdopodobnie chcielibyśmy, aby tylko zalogowani użytkownicy mogli wysyłać żądania do API i tym samym uzyskać dostęp do chronionych zasobów. Wykorzystując opisywaną wcześniej usługę Amazon Cognito – sprawa jest prosta.

Jednak aby lepiej zrozumieć mechanizm ograniczenia dostępu do API wykorzystujący integrację z Cognito, zacznijmy od szybkiego wyjaśnienia czym jest JWT (ang. JSON Web Token) [2]. Jest to standard opisujący bezpieczny sposób wymiany informacji w formie obiektu JSON, który zostaje zakodowany i podpisany kryptograficznie, dzięki czemu możemy być (niemal) pewni, że dane rzeczywiście pochodzą z oczekiwanego przez nas źródła.

Typowy token JWT składa się z trzech części – nagłówka, danych właściwych (tzw. payload) oraz podpisu (sygnatury) – rozdzielonych kropką. Usługa Amazon Cognito, w przypadku poprawnego uwierzytelnienia użytkownika, zwraca do naszej aplikacji aż trzy tokeny JWT:

  • ID token
  • Access token
  • Refresh token

Dwa pierwsze z nich zawierają poświadczenia dotyczące tożsamości użytkownika i są ważne przez godzinę od momentu wygenerowania. Refresh token umożliwia ponowne wygenerowanie ID oraz Access tokenu po upływie terminu ich ważności, bez konieczności ponownego uwierzytelniania użytkownika. Dla każdej puli Cognito generowane są dwie pary kluczy kryptograficznych RSA. Jeden z kluczy prywatnych jest wykorzystywany do utworzenia cyfrowej sygnatury tokenu.

Znając klucz publiczny, zarówno nasza aplikacja kliencka, jak i API Gateway mogą łatwo zweryfikować, czy użytkownik posługujący się danym JWT rzeczywiście pochodzi z naszej puli, a także czy nie próbuje podszywać się pod innego użytkownika. Każda próba ingerencji w ciąg znaków tworzący token sprawi, że sygnatura stanie się nieważna.

Posiadając taką wiedzę, powoli zbliżamy się do wyjaśnienia sekretu działania authorizera zintegrowanego z pulą Cognito. Spójrzmy na zmodyfikowaną wersję przedstawionego wcześniej diagramu architektury.

Architecture_Modified diagram

Żądanie do REST API, wysyłane przez aplikację kliencką, tym razem zawiera dodatkowy nagłówek HTTP o nazwie Authorization. Jako wartość tego nagłówka ustawiamy ID token lub Access token, przesłany wcześniej do aplikacji w odpowiedzi na pomyślne uwierzytelnienie użytkownika. Usługa API Gateway, zanim przekaże żądanie do funkcji Lambda, upewni się, czy token rzeczywiście został podpisany kluczem powiązanym z właściwą pulą Cognito oraz czy termin ważności tokenu nie upłynął. Jeśli weryfikacja zakończy się błędem, żądanie zostanie odrzucone.

Zatem nawet jeśli potencjalny atakujący odgadnie adres URL endpointu, nie będzie w stanie pomyślnie wysłać żadnego żądania do API nie będąc zarejestrowanym użytkownikiem naszej aplikacji. Rozwiązanie jest proste, eleganckie i bezpieczne, a przy okazji stanowi kolejny argument za tym, aby używać usługi Amazon Cognito.

Innym dostępnym typem authorizera jest Lambda authorizer, który przydaje się w sytuacjach, kiedy z jakiegoś powodu nie możemy użyć Cognito. Jak sama nazwa wskazuje, to rozwiązanie wykorzystuje funkcję Lambda uruchamianą w momencie nadejścia żądania do endpointu. Funkcja zawiera naszą własną logikę weryfikacji żądania na podstawie dostarczonego tokenu, bądź też na podstawie nagłówków i parametrów przesłanych razem z tym żądaniem. Jako wynik działania Lambdy musi zostać zwrócony obiekt zawierający politykę IAM, która określa czy API Gateway powinien zaakceptować, czy odrzucić żądanie.

Bezpieczne funkcje Lambda

Pisząc o bezpieczeństwie aplikacji serverless, nie sposób pominąć kwestii dotyczących funkcji Lambda. Jak już zostało wspomniane, dostawca usług chmurowych odpowiada za właściwą konfigurację środowiska uruchomieniowego i całej powiązanej z nim infrastruktury, a programista – za napisanie kodu wolnego od podatności i luk mogących stanowić wektor ataku. Jedną z takich podatności, wymienioną na pierwszym miejscu w zestawieniu OWASP Serverless Top 10 [3], jest tzw. wstrzyknięcie (ang. injection), które wielu osobom może się kojarzyć z popularnym i dobrze opisanym w rozmaitych źródłach atakiem SQL Injection.

Dla przypomnienia: polega on na niezamierzonym wykonaniu zapytania SQL (lub jego fragmentu) umieszczonego przez atakującego w danych wejściowych, które nasza aplikacji przetwarza bez uprzedniego filtrowania. W modelu serverless, tego typu dane niekoniecznie muszą pochodzić bezpośrednio z interfejsu użytkownika.

Funkcje Lambda często są uruchamiane w odpowiedzi na nadejście określonego zdarzenia z innej usługi AWS, jak np.: utworzenie nowego pliku
w wiadrze S3, modyfikacja rekordu w tabeli DynamoDB czy pojawienie się powiadomienia w topicu SNS. Obiekt event, który przechowuje zestaw informacji na temat takiego zdarzenia i jest dostępny w głównej metodzie Lambdy, w pewnych przypadkach również może zawierać kod „wstrzyknięty” przez atakującego.

Z tego powodu niezwykle istotne jest, aby każdy bajt danych wejściowych, który trafia do naszej funkcji z dowolnego źródła, został odpowiednio przefiltrowany, zanim zostanie użyty w zapytaniu SQL lub w poleceniu powłoki systemowej. Jakie niebezpieczeństwo grozi nam w tym drugim przypadku? Wszystkie popularne języki programowania posiadają funkcje lub biblioteki umożliwiające wykonywanie poleceń powłoki z poziomu kodu. Z technicznego punktu widzenia, nic nie stoi na przeszkodzie, aby robić to również w funkcjach Lambda, ale…

W celu lepszego zrozumienia możliwego wektora ataku, przypomnijmy pokrótce podstawy działania usługi Lambda.

AWS Lambda_Overview

Źródło: Security Overview of AWS Lambda [1]

Do uruchamiania naszych funkcji, AWS używa maszyn wirtualnych specjalnego typu, tzw. MicroVMs [4]. Każda instancja MicroVM może być wykorzystana ponownie dla potrzeb różnych funkcji w obrębie danego konta. Również każda taka instancja może zawierać wiele środowisk wykonawczych (są to pewnego rodzaju kontenery), w których działa wybrane przez użytkownika środowisko uruchomieniowe, np. Node.js, JVM czy Python. Środowiska wykonawcze nie są współdzielone pomiędzy różnymi funkcjami, jednak – co istotne – mogą być wykorzystane ponownie do uruchomienia kolejnych wywołań tej samej Lambdy.

Zatem jeśli w kodzie wywołujemy polecenie powłoki systemowej, które jest tworzone dynamicznie i zawiera nieprzefiltrowane dane wejściowe, atakujący może wykorzystać ten fakt do przejęcia kontroli nad środowiskiem wykonawczym, a tym samym nad innymi wywołaniami funkcji. Często pozwoli mu to na uzyskanie dostępu do poufnych informacji przechowywanych na przykład w bazie danych bądź w plikach umieszczonych w katalogu /tmp, a także zniszczenie niektórych zasobów aplikacji. Podatność ta została opisana pod nazwą RCE (ang. Remote Code Execution) [5].

Oprócz filtrowania i walidacji danych wejściowych, jedną z najważniejszych praktyk bezpieczeństwa dotyczących usługi AWS Lambda jest stosowanie zasady minimalnych uprawnień (ang. principle of least privilege). Aby ją poprawnie wdrożyć, musimy zadbać o spełnienie dwóch założeń:

  • Każda Lambda w naszej aplikacji powinna posiadać przypisaną osobną rolę IAM. Niedopuszczalne jest tworzenie jednej, wspólnej roli dla wszystkich funkcji.
  • Rola każdej Lambdy powinna zezwalać na tylko te operacje, które rzeczywiście są wykonywane. Należy unikać stosowania symbolu wieloznacznego (*, tzw. wildcard) w politykach.

Prosty przykład praktycznego zastosowania zasady: jeśli zadaniem danej funkcji jest odczyt rekordów z bazy danych DynamoDB, to przypisana rola IAM musi zezwalać tylko na wykonanie operacji odczytu z konkretnej, potrzebnej w tym przypadku tabeli. W pewnych sytuacjach możemy pójść o krok dalej i ograniczyć dostęp tylko do wybranych rekordów w tabeli oraz wybranych atrybutów tych rekordów [6]. Nawet jeśli atakujący będzie w stanie nas przechytrzyć i uzyska dostęp do środowiska wykonawczego Lambdy, stosowanie zasady minimalnych uprawnień pozwoli znacznie ograniczyć rozmiary wyrządzonych przez niego szkód.

Przechowywanie danych dostępowych

Łatwo zauważyć, że korzystając z bazy danych Amazon DynamoDB nie musimy martwić się o proces nawiązywania połączenia oraz uwierzytelniania za pomocą nazwy użytkownika i hasła, co zwykle ma miejsce w przypadku serwerów bazodanowych. Komunikacja odbywa się za pośrednictwem protokołu HTTP(S), a każde wysyłane żądanie zawiera kryptograficzną sygnaturę. Programista zwykle nie musi znać niskopoziomowych szczegółów działania tego interfejsu, ponieważ może wykorzystać wygodne, wysokopoziomowe API używając AWS CLI lub pakietów AWS SDK.

Jednak w niektórych zastosowaniach pojawia się potrzeba użycia innej bazy danych, a to zwykle oznacza konieczność przechowywania danych dostępowych gdzieś w „otchłani” naszej aplikacji. Kiepskim pomysłem jest zapisanie ich bezpośrednio w kodzie funkcji Lambda, co często oznacza, że trafią one później do repozytorium Git. Lepszym rozwiązaniem może być wykorzystanie zaszyfrowanych zmiennych środowiskowych Lambdy, a jeszcze lepszym – użycie usługi AWS Secrets Manager. Pozwala ona na bezpieczne przechowywanie haseł, kluczy dostępowych do API oraz innych poufnych informacji. Programista może łatwo pobrać takie dane w kodzie funkcji Lambda wywołując odpowiednią metodę z pakietu AWS SDK.

Jeśli nasza aplikacja korzysta z serwera bądź klastra bazodanowego stworzonego za pomocą usługi Amazon RDS, możemy skorzystać z uwierzytelniania IAM [7]. Po odpowiednim skonfigurowaniu bazy danych oraz roli IAM przypisanej do funkcji Lambda, jednym wywołaniem metody z AWS SDK pobieramy tymczasowy, ważny przez 15 minut token dostępowy, którego następnie używamy zamiast hasła w standardowej procedurze nawiązywania połączenia z bazą. Wymagane jest, aby było to szyfrowane połączenie SSL, co dodatkowo podnosi poziom bezpieczeństwa rozwiązania. Należy jednak pamiętać o pewnych ograniczeniach – np. w przypadku silnika MySQL możliwe jest nawiązanie w ten sposób maksymalnie 200 nowych połączeń na sekundę.

Podsumowanie

Warto pamiętać, że wybór modelu serverless nie zwalnia nas całkowicie z konieczności zajmowania się sprawami związanymi z bezpieczeństwem, jednak wykorzystując narzędzia i usługi dostępne w chmurze AWS możemy zdecydowanie ułatwić sobie to zadanie. Szczegółowy opis wszystkich możliwych zagrożeń spotykanych w tej architekturze oraz sposobów przeciwdziałania im, to materiał wystarczający na napisanie co najmniej jednej opasłej księgi.

Niniejszy artykuł porusza tylko wybrane zagadnienia i jest dobrym punktem wyjścia do dalszego pogłębiania wiedzy na ten temat. Zachęcam do przejrzenia materiałów uzupełniających, a także objerzenia nagrania z prelekcji zatytułowanej „Securing enterprise-grade serverless apps”, na podstawie której powstał ten artykuł.

Materiały uzupełniające

  1. Amazon Web Services, Inc., Security Overview of AWS Lambda. An In-Depth Look at Lambda Security.
  2. Auth0, Inc., JSON Web Token Introduction
  3. The OWASP Foundation, OWASP Serverless Top 10
  4. Amazon Web Services, Inc., Firecracker
  5. Yuval Avrahami, Gaining Persistency on Vulnerable Lambdas
  6. Amazon Web Services, Inc., Using IAM Policy Conditions for Fine-Grained Access Control
  7. Amazon Web Services, Inc., IAM Database Authentication for MySQL and PostgreSQL

_Wszystkie wpisy z tej kategorii

blogpost
Artykuły

Jak wdrożyć założenia Przemysłu 4.0 mądrzej, szybciej i łatwiej?

Pojęciem związanym z Przemysłem 4.0 jest Smart Factory - inaczej mówiąc "inteligentna fabryka". Ten typ fabryki oparty jest na zintegrowanych systemach przy wykorzystaniu przemysłowego Internetu Rzeczy i nowych metod organizacji produkcji. Celem jest zapewnienie wysokiego poziomu personalizacji produktów i realizacja procesów produkcyjnych przy minimalnym nakładzie pracy. Wdrożenie koncepcji Smart brzmi dobrze, ale wydaje się trudne do realizacji? Bez obaw, to będzie interesująca przygoda, pod warunkiem że po swojej stronie masz odpowiedniego przewodnika.

Czytaj więcej
blogpost
Artykuły

6. biznesowych korzyści modernizacji aplikacji w chmurze Amazon Web Services. Pokonaj dług technologiczny

Oczywiste jest, że firmy muszą nadążać za szybko zmieniającym się krajobrazem cyfrowym, aby pozostać konkurencyjnymi. Modernizacja aplikacji w chmurze jest kluczową strategią aktualizacji przestarzałych systemów. Bez tego działania, nie da się w pełni wykorzystać zalet jakie oferuje chmura, takich jak te zapewniane przez jedną z najpopularniejszych na świecie platform chmurowych, Amazon Web Services (AWS). W […]

Czytaj więcej
blogpost
Artykuły

Podejście Cloud Native: Modernizować istniejące czy budować od podstaw natywne aplikacje chmurowe?

Czym są aplikacje wie chyba każdy. A jak jest z pojęciem Cloud Native? Być może każdy, no prawie każdy, coś słyszał i będzie miał swoje zdanie. Dobrze, to czym jest tak naprawdę Cloud Native Applications ( aplikacje natywne w chmurze / natywne aplikacje chmurowe) i samo podejście Cloud Native? Czy warto tworzyć nowe lub modernizować istniejące aplikacje do modelu Cloud Native, by usprawnić systemy i/lub przezwyciężyć dług technologiczny? W tym artykule postaram się odpowiedzieć na powyższe pytania oraz pokazać dlaczego podejście Cloud Native może być kluczowym elementem sukcesu transformacji cyfrowej każdej organizacji.

Czytaj więcej
blogpost
Artykuły

Czy sztuczna inteligencja zdominuje wizję przyszłości i rozwoju cloud computing?

Początek roku to okres wzmożonych podsumowań minionych miesięcy, a także przygotowywania planów na kolejne. W tym czasie pojawia się wiele mniej lub bardziej trafnych predykcji na temat tego, czego możemy spodziewać się w najbliższej przyszłości w ramach oferowanych przez dostawców usług w chmurze. W przypadku chmury obliczeniowej możemy z dużym prawdopodobieństwem przewidzieć, co w takich […]

Czytaj więcej
blogpost
Artykuły

Bezpieczeństwo chmury Azure: Jak zapewnić model Zero Trust i wykorzystać AI na swoją korzyść? (cz.2)

W poprzednim artykule poruszyliśmy temat czym jest model Zero Trust i dlaczego jest tak istotny w zapewnieniu najwyższego poziomu bezpieczeństwa zasobów firmy w chmurze i poza nią. W tej części będziemy kontynuować przegląd usług chmury publicznej Azure a także skupimy się na wątku AI w temacie bezpieczeństwa. Microsoft Defender dla chmury Microsoft Azure to rozległe […]

Czytaj więcej
blogpost
Artykuły

Bezpieczeństwo chmury Azure: Jak zapewnić model Zero Trust i wykorzystać AI na swoją korzyść? (cz.1)

Od czasu globalnej popularyzacji pracy zdalnej, zespoły cyberbezpieczeństwa stają przed coraz większymi wyzwaniami, aby zapewnić skuteczny i bezpieczny dostęp do krytycznych zasobów oraz danych organizacji, a także zagwarantować ich bezpieczne przechowywanie. Skomplikowane ataki phishingowe (wpływające krytycznie na bezpieczeństwo plików oraz infrastruktury), nie rzadko wspomagane AI, w wyniku których ujawniane są dane uwierzytelniające, pozwalają na ataki z […]

Czytaj więcej
blogpost
Artykuły

Czy Edge to nowa chmura?

Wiele organizacji, które przyjęły chmurę, traktuje Edge jako naturalne rozszerzenie swoich rozwiązań opartych na niej. Z drugiej strony, te firmy, które są na samym początku podróży ku chmurze, są często znacznie bardziej świadome możliwości obu technologii, więc rozważają ich równoczesne wykorzystanie od samego początku.Pytania są więc następujące:Czy Edge zastąpi chmurę? Czy korzystanie z Edge'a w chmurze przeniesie ciężar rozwoju oprogramowania z powrotem do on-premise? Wspólnie zastanówmy się nad odpowiedziami, zapraszam do lektury.

Czytaj więcej
blogpost
Artykuły

Obliczenia kwantowe: Kot Schrödingera zadomowił się w chmurze

Zapnij pasy i dołącz  do mnie w podróży do świata, w którym kot może być zarówno martwy, jak i żywy, a cząsteczka może znajdować się w dwóch miejscach jednocześnie. Odkryjemy fascynujący świat obliczeń kwantowych (Quantum Computing) i ich rolę w przetwarzaniu w chmurze.

Czytaj więcej
blogpost
Artykuły

Czy chmura hybrydowa i multi-cloud obronią Cię przed vendor lock-in? Czy rzeczywiście musisz się tego wystrzegać?

Uzależnienie od dostawcy (vendor lock-in), to pojęcie nad wyraz często łączone z branżą IT, a w ostatnich latach szczególnie z chmurą obliczeniową, chociaż zdecydowanie nie jest z nimi nierozerwalnie związane. Przez ekonomistów rozpatrywane było w szerszym kontekście na długo przed tym, kiedy świat po raz pierwszy usłyszał o AWS czy Azure. Z perspektywy klienta oraz użytkownika, zazwyczaj bywa postrzegane w negatywnym świetle, niejednokrotnie wywołując niechęć i strach przed skorzystaniem z danej usługi lub produktu.Na pierwszy rzut oka wydaje się, że w obszarze chmury publicznej problem nie jest błahy. Nawet główni beneficjenci zjawiska, czyli najwięksi dostawcy usług chmurowych, zdecydowali się poruszyć to zagadnienie na swoich oficjalnych stronach internetowych, więc najwyraźniej coś musi być na rzeczy…A czy faktycznie jest, sprawdzimy w tym artykule. Przyjrzymy się ryzykom, jakie niesie za sobą vendor lock-in dla organizacji planujących adopcję chmury. Zastanowimy się również, czy skorzystanie z usług kilku dostawców (multi-cloud) jednocześnie może być dobrą receptą na poprawę sytuacji. Ponadto, weźmiemy pod lupę chmurę hybrydową.

Czytaj więcej
blogpost
Artykuły

(r)Ewolucja w zarządzaniu danymi produkcyjnymi. Platformy danych w chmurze

Platformy danych oparte na chmurze stają się przełomem w zarządzaniu danymi produkcyjnymi. W przeszłości firmy zmagały się z zarządzaniem ogromnymi ilościami danych generowanych przez procesy produkcyjne bez wsparcia automatyzacjami, AI i często w modelu rozproszonym tzn. dane pochodziły i były wyświetlane w różnych źródłach. Nie było to ani wygodne, ani efektywne. Na szczęście ten czas już minął.

Czytaj więcej
blogpost
Artykuły

Jak AI Data Discovery pomaga firmom produkcyjnym?

Odkryj przyszłość przemysłu produkcyjnego dzięki usłudze AI Data Discovery i chmurze! Poznaj, jak te technologie i usługi eliminują straty i zwiększają efektywność branży produkcyjnej.

Czytaj więcej
blogpost
Artykuły

Migracja do chmury i modernizacja aplikacji Airline Rewards: mapowanie wymagań architektury

W tym artykule przeprowadzę Cię przez kroki, wybory techniczne i kompromisy związane z migracją i modernizacją aplikacji do chmury publicznej, kładąc nacisk na podejście wykraczające poza podejście typu „lift & shift” i PaaS. Na podstawie rzeczywistego przykładu rozważymy cele biznesowe, architekturę oraz potrzeby funkcjonalne/niefunkcjonalne. Czynniki biznesowe zostaną omówione w następnym artykule.

Czytaj więcej
blogpost
Artykuły

Jak właściwie rozumieć chmurę publiczną w 2023? I dlaczego jest to takie trudne?

Chmura ciągle się zmienia i ewoluuje. To co widzimy dziś, to nie to samo było wczoraj i nie to samo co będzie jutro. Jedyną stałą jest zmiana. Dziś rozmowy o zmianach nie prowadzi się tylko z działami IT, ale także i przed wszystkim z biznesem, z włączeniem działów marketingu, HR, czy finansów. Każdy z nich ma inne potrzeby i tak się składa, że wszystkie je można zaadresować chmurą.

Czytaj więcej
blogpost
Artykuły

Przyspieszenie wdrożenia koncepcji Przemysłu 4.0

Cyfrowa transformacja i podążanie w kierunku idei Przemysłu 4.0 oraz Inteligentnej Fabryki (w AWS) nie należą do łatwych. Najczęstsze przeszkody to utknięcie na etapie pilotażu i brak kontynuacji transformacji w kolejnych fabrykach (tj. skalowania). Brak skalowania, czyli brak kontynuacji transformacji kolejnych zakładów, to temat, na którym skoncentrujemy się w tym artykule. W tym przypadku producenci zmagają się z trudnościami w efektywnym odtworzeniu początkowych sukcesów cyfrowej transformacji (wdrożenia pierwszego MVP) w różnych lokalizacjach. Ten brak skalowalności może doprowadzić do spowolnienia tempa realizacji koncepcji Przemysłu 4.0 na szerszą skalę, a nawet do utraty poparcia zarządu.

Czytaj więcej
blogpost
Artykuły

Jak zbliżyć się do Przemysłu 4.0?

Rozwijaj biznes dzięki cyfrowej transformacji. Zmiany obejmują także komunikację i przygotowanie pracowników – bez ich poparcia i zaangażowania, wdrożenie będzie znacznie trudniejsze. Sprawdź, jak przygotować swoje zespoły do wdrożenia założeń Przemysłu 4.0 i Inteligentnej Fabryki.

Czytaj więcej
blogpost
Artykuły

Jak optymalizować koszty chmury AWS z wykorzystaniem FinOps?

Chmura to nie on-premise Inżynierowie tworząc architekturę i powołując nowe zasoby w chmurze w sposób niejawny podejmują decyzje zakupowe. Czasem wielokrotnie wciągu jednego dnia! Każda z nich ma wpływ na wielkość rachunku wystawionego na koniec miesiąca przez dostawcę chmury publicznej. Dla organizacji z długą historią jest to zupełnie nowa rzeczywistość. Działom finansowym trudno odnaleźć się […]

Czytaj więcej
blogpost
Artykuły

Chmura napędza cyfrową transformację

Chmura coraz częściej stanowi kluczowy aspekt powodzenia procesu transformacji cyfrowej. Rozmowa z Christianem Thiem, starszym analitykiem biznesowym w TT PSC Germany GmbH, dostarczy odpowiedzi na pytania: co należy uwzględnić w harmonogramie migracji do chmury oraz jak przygotować organizację do jej wdrożenia?

Czytaj więcej
blogpost
Artykuły

Co musisz wiedzieć o serverless computing?

Serverless cmputing nadal budzi sporo wątpliwości, szczególnie wśród tych środowisk, które właśnie zaczynają korzystanie z usług chmurowych lub dopiero planują migrację do chmury swoich systemów. Na najważniejsze pytania dotyczące tego rozwiązania spróbujemy odpowiedzieć w niniejszym artykule.

Czytaj więcej
blogpost
Artykuły

Czym jest DevOps as a service i czemu warto z tego skorzystać?

Oszczędność, skrócenie czasu wdrażania zmian oraz weryfikowanie ich poprawności – to tylko kilka przykładowych korzyści, których gwarantem jest DevOps. Ta innowacyjna metodologia wprowadziła nową jakość pracy nad projektami IT. Bazuje na kooperacji autonomicznych obszarów: inżynierii oprogramowania, administracji oraz kwestii dotyczących bezpieczeństwa i jakości.

Czytaj więcej
blogpost
Artykuły

9 powodów, dla których powinno się wykorzystywać chmurę w prowadzeniu biznesu

Zgodnie z raportem firmy RightScale „2019 State of the Cloud Report from Flexera”, aż 94% firm używa chmury. To nie przypadek, że tyle przedsiębiorstw przechodzi na rozwiązania cloud computing. Z tego artykułu dowiesz się, dlaczego to taka popularna koncepcja, jak Twój biznes skorzysta na wdrożeniu chmury i dlaczego ten, kto jeszcze jej nie używa, zostaje z tyłu za konkurencją.

Czytaj więcej
blogpost
Artykuły

Jak zacząć przygodę z Azure i przygotować się do certyfikacji AZ-900

Zapotrzebowanie na specjalistów w obszarze Cloud stale rośnie. Jak zdobyć szeroki zakres kompetencji i szybko odnaleźć się w temacie chmury? Najlepiej zacząć od solidnych podstaw, czyli certyfikatu Azure AZ- 900.

Czytaj więcej
blogpost
Artykuły

Chmura na czas kryzysu, czyli jak usprawnić pracę w swojej firmie

Świat, który znaliśmy przez ostatnie lata mocno się zmienia. Wymusza na nas zmianę przyzwyczajeń, a także sposobów w jaki pracujemy i realizujemy nasze codzienne obowiązki. Zarówno te zawodowe, jak i te prywatne. Okoliczności, w których się znaleźliśmy sprawiły, że wiele osób pracuje teraz zdalnie.

Czytaj więcej
blogpost
Artykuły

Parametry SSM w automatyzacji AWS

Jakiś czas temu zostałem zaangażowany w projekt, który miał dostarczyć Windchilla w sposób wysoko dostępny – w sumie nic nowego, klaster załatwia sprawę i w zasadzie można by na tym zakończyć temat, ale…

Czytaj więcej
blogpost
Artykuły

Jak dotknęliśmy chmur – relacja z AWS re:invent 2019

Udział w konferencji AWS re:Invent wymaga od uczestników, pomijając finansowanie, nieco zaangażowania i odrobiny samozaparcia. W naszym przypadku zakup wejściówek na konferencje w sierpniu rozpoczął długi proces przygotowywania i planowania udziału w tym wydarzeniu.

Czytaj więcej
blogpost
Artykuły

Najważniejsze nowości z AWS re:Invent 2019

Ciekawi Cię jakie nowości zostały zaprezentowane na AWS re:Invent, ale nie masz czasu stale przeglądać doniesień z Vegas? Nie musisz już szukać. Specjalnie dla Ciebie, w jednym miejscu, zebraliśmy wszystkie najważniejsze zapowiedzi, które są ogłaszane podczas trwania tej konferencji.

Czytaj więcej
blogpost
Artykuły

Jak wykorzystać Talend Open Studio w branży medycznej?

Wykorzystywanie nowoczesnych technologii w medycynie jest coraz powszechniejsze. Papierowe karty pacjentów wypadają z obiegu i zastępują je elektroniczne formy przechowywania danych. Proces digitalizacji służby zdrowia właśnie trwa! W jakich obszarach? Odpowiedź na to pytanie znajdziesz w dalszej części artykułu.

Czytaj więcej
blogpost
Artykuły

Czym jest chmura Amazon Web Services?

Chmura obliczeniowa to jedna z najdynamiczniej rozwijających się technologii na świecie. Stopniowo wypiera tradycyjne rozwiązania serwerowe, zgarniając dla siebie coraz większą część rynku. Firma badawcza Gartner przewiduje, że w 2019 całkowite wydatki na chmurę publiczną wzrosną o 17,5% i wyniosą 214 miliardów dolarów. Dla porównania budżet Polski na 2019 przewiduje przychody na poziomie 387,7 mld zł, czyli prawie 100 mld dolarów. Nie ma wątpliwości, że to duży i atrakcyjny to rynek.

Czytaj więcej
blogpost
Artykuły

Dlaczego serverless jest przyszłością aplikacji

Co kilka lat, w świecie IT, pojawia się nowe, przełomowe rozwiązanie. Aktualnie, wszystkie oczy są skupione na Machine Learning(ML) oraz Sztucznej Inteligencji(AI). Wcześniej były to kontenery, do których istnienia, chyba już wszyscy zdążyli przywyknąć. Jak się okazuje, to co kilka lat temu było absolutną nowością, dziś jest rutyną.

Czytaj więcej
blogpost
Artykuły

Windchill Single Sign On – jak z Amazon Web Services dostać się do Active Directory w sieci klienta?

Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej weryfikacji (jakie mamy możliwości), okazało się, że możemy użyć ADFS. Klient już wykorzystywał ADFS pod inne usługi, zatem mogliśmy pominąć etap przekonywania Security Team. Po kilku dniach walki z różnymi zawiłościami Ping […]

Czytaj więcej
blogpost
Artykuły

Budujemy własne AWS Echo (z AWS Alexa na pokładzie)

Jak zamienić (nie)zwykłe RaspberryPi w AWS Echo komunikujące się z otoczeniem przy użyciu modułu konwersacyjnego AWS Alexa? Jak z jej pomocą zapytać o pogodę w Londynie, poprosić o wyłączenie świateł w domu czy umówić wizytę u dentysty? Jak w paru krokach rozszerzyć Aleksę o (praktycznie) dowolne funkcjonalności? Jak sprawdzić czy słuchający nas ludzie są zadowoleni, […]

Czytaj więcej
blogpost
Artykuły

Dlaczego rozwiązania Cloud?

Rozwiązania Cloudowe, czyli tak zwane Chmury Obliczeniowe, są w Polsce o wiele mniej popularne niż na Zachodzie Europy i w Stanach Zjednoczonych. Rynek jest młody i dopiero się kształtuje. Klienci stopniowo nabierają zaufania do tego typu rozwiązań.   Obawy polskich firm związnane z bezpieczeństwem / „chmurowe” doświadczenia przedsiębiorstw z całego świata. Rozwiązania Cloudowe oferują szereg […]

Czytaj więcej
blogpost
Artykuły

Rosnąca popularność modelu usług Serverless

Jeszcze nie tak dawno na DevOps Days Warsaw 2016 przewijały się przepowiednie o konteneryzacji i Dockerze jako technologii, która jest przyszłością. Każdy kto wówczas zainwestował swój czas w naukę Dockera z pewnością dziś tego nie żałuje. W TTPSC uważamy, że konteneryzacja nie jest ostatnim etapem ewolucji i zdecydowanie stawiamy na rozwiązania serverless jako ostateczny wynik […]

Czytaj więcej
blogpost
Artykuły

Chmura to przyszłość

Obecnie aż 63% firm przechodzi cyfrową transformację. Klasyczne, papierowe dokumenty są wypierane przez swoje elektroniczne odpowiedniki. Dzięki temu działy takie jak administracja czy księgowość znacznie zredukowały swoje wydatki oraz usprawniły działanie, gdyż przepływ danych stał się znacznie lepszy. Jednak magazynowanie tak dużej ilości dokumentacji elektronicznej nie jest prostym zadaniem. Dlatego w ostatnich czasach pojawiła się […]

Czytaj więcej
blogpost
Artykuły

Transition Technologies PSC uzyskało tytuł Standard Consulting Partner Amazon Web Services (AWS)

Z dumą oświadczamy, że partnerstwo Transition Technologies PSC oraz Amazon Web Services (AWS) wkroczyło na kolejny poziom. Kilka dni temu uzyskaliśmy status Standard Consulting Partner AWS w Polsce. Jest to potwierdzenie ze strony Amazon, że nasza firma posiada certyfikowanych specjalistów i ekspertów dziedzinowych, którzy są w stanie efektywnie pomagać klientom projektować, budować, migrować oraz zarządzać […]

Czytaj więcej

Zostańmy w kontakcie

Skontaktuj się