GUI w skryptach – porównanie

Zadanie

zadanie jest proste – napisać GUI, które pozwoli wyłączyć maszynę w Azure z opcją force. tego normalnie z interfejsu zrobić się nie da, a operacja potrzebna. chodzi o przeniesienie zadania z 2giej czy 3ciej linii wsparcia do 1szej, czyli nie ma opcji na jakąkolwiek linię poleceń. musi być GUI.

 

poniżej dwa skrypty, które realizują to samo zadanie. jeden napisany w tym co PS daje [z małym wyjątkiem], drugi w Formsach. przykład ma posłużyć do porównania tych metod i pozwolić się zastanowić jakie są ‘za’ i ‘przeciw’ dla obu.

(prawie) natywny PowerShell

pełny skrypt można pobrać z GitHuba, poniżej omówienie fragmentów.

założeniem tej wersji jest szybkość działania i uniwersalność. nie korzystam póki co z wersji PS Core ale na pewno korzystanie z biblioteki forms nie będzie możliwe. dla Core można korzystać z XAML UI, którego również jeszcze nie testowałem. jak już pisałem – jedną z bolączek pisania skryptów z GUI jest już sam dobór bibliotek i decyzja ‘gdzie ten skrypt będzie uruchamiany i przez kogo’ /:

dla tego ‘natywne’ skrypty zachowują lepszą kompatybilność i uniwersalność.

niestety natywnych kontrolek jest niezmiernie mało. najważniejszą jest out-GridView, które umożliwia wyświetlenie listy lub obiektów w postaci interaktywnej tabeli, pozwalając na sortowanie, filtrowanie etc. pozwala również na wybranie pojedynczego lub wielu elementów – czyli może być przydatny również wtedy, kiedy chcemy pozwolić użytkownikowi wybrać obiektów do dalszego przetworzenia. i choć daje wiele możliwości, to równocześnie bardzo niewielką kontrolę.

fragment kodu do którego się odwołuję to:

function select-RG {
  param(
    $RGList 
  )
  write-host -ForegroundColor Yellow "Select Resource Group VM resides on"
  $RG=$RGList|out-gridview -title 'Select Resource Group' -OutputMode Single
  if([string]::isNullOrEmpty($RG)) {
    write-host 'cancelled by user. quitting' -foreground Yellow
    exit -1
  }
  write-host "$($RG.ResourceGroupName) chosen. reading VMs..."
  return $RG.ResourceGroupName
}

w szczególności linia pokazująca listę odczytanych Resource Groups w postaci interaktywnej. Out-GridView ‘daje-to-co-daje’ czyli nie da się kontrolować wyglądu okna. to co możemy zrobić to:

  • title: ustawić tytuł okna. ponieważ nie jest to coś, co rzuca się specjalnie w oczy, staram się poprzedzać to dodatkowo odpowiednim komunikatem na ekranie. zwiększy to prawdopodobieństwo, że użytkownik tego nie przegapi i będzie widział po co w ogóle jakieś okno mu wyskaqje na ekran.
  • OutputMode: przyjmuje wartości ‘single’ lub ‘multiple’ dzięki czemu możemy kontrolować czy oczekujemy pojedynczego wyniku czy listy. np. jeśli piszemy skrypt, który usuwa pliki – chcemy mieć możliwość wybrania od razu wielu. tutaj użyte jest ‘single’ co bloqje opcję multi-choice. dodatkowo ten parametr *zastępuje* passthru.
  • PassThru: to starsza wersja, nie jestem pewien w której wersji pojawiło się OutputMode… w każdym razie sam ‘ogv’ [bo taki ma alias] po prostu wyświetla. można się pobawić i zamknąć. tyle. natomiast dodanie opcji PassThru [lub użycie OutputMode] spowoduje dodanie guzika wyboru ‘OK’, po wybraniu którego wybrane elementy zostaną przesłane jako wyniki [pipelined].

siła tkwi w prostocie. chwilę później jednak można zobaczyć:

do {
  #choose RG
  $ResourceGroupName=select-RG -RGList $RGsInThisSub
  $VMlist=get-VMList -RGname $ResourceGroupName
  if([string]::isNullOrEmpty($VMlist)) {
    write-host "This Resource Group do not contain any VMs. Do you want to select another RG?"
    switch (
      [System.Windows.Forms.MessageBox]::show($this,"Choose another Resource Group?",'CONFIRM','OKCancel') 
    ) {
      'OK' {
        #do nothing - VMList is null which will trigger loop
      }
      'Cancel' {
        Write-Host -ForegroundColor Yellow "operation cancelled by the user. quitting."
        exit -1
        } 
    }
  }
} while( [string]::isNullOrEmpty($VMlist) )

czemu nagle pojawia się Forms? to niestety sqcha twórców PowerShell – o ile WScript dysponował prostym okienkiem OK/Cancel, o ile jest OGV w PS… o tyle nie ma takiego prostego okienka OK/Cancel w PS.

co ciekawe, można takie okienko wyświetlić bez Forms! w taki sposób:

Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::show("Choose another Resource Group?",'CONFIRM','OKCancel')

pomimo, że wyglądają bardzo podobnie, i dają niemal ten sam efekt, pod spodem wydarzają się trochę inne rzeczy. jeden jest częścią PresentationFramework drugi Forms, mają inne konstruktory. lepiej używać Formsowego z dwóch powodów:

  • zazwyczaj to nie będzie jedyny element GUI, więc jeśli importujesz biblioteki .NET, lepiej już wybrać tą bardziej rozbudowaną w tym kierunq
  • wersja z PF nie pozwala w konstruktorze na zdefiniowanie okna nadrzędnego – magiczne ‘$this’ na pierwszej pozycji show($this,”Choose another Resource Group?”,’CONFIRM’,’OKCancel’)  – a w efekcie takie okienko często lądowało pod spodem czegoś aktywnego.

a co z readKey?!

jak już coś pisaliście co wymaga interakcji, powinniście zadać pytanie – czemu nie użyć readKey? natywne, nie wymaga importu bibliotek, szybsze … i tak dalej.

zgoda. ale celem nadrzędnym jest wygoda endusera i założenie, że nie jest bystrym inżynierem (; kiedy zrobiłem readKey, a skrypt miał mieć GUI, sam łapałem się na tym, że czekałem i czekałem… aż zorientowałem się, że to skrypt czeka na mnie, a nie odwrotnie. załamanie logiki – tutaj interfejs a tu linia poleceń – jest bardzo złym podejściem. albo decydujemy się robić skrypt tak, albo inaczej – ale musi być spójnie. inaczej ani nie jest łatwy w użyciu ani prosty w strukturze.

readKey to nie GUI tylko metoda na interakcję bez GUI.

wersja Forms

całość do pobrania z GitHub . kilka uwag n00ba dotyczących pisania PS+Forms.

pierwszą rzeczą jaka rzuca się oczy to narzut ilości kodu. do wykonania mamy jedno polecenie (jedna linijka). w wersji opisywanej wcześniej wyszło 126 linii kodu, tutaj mamy już prawie 19o. jasne się staje że podstawowym problemem będzie możliwy bałagan wynikający z samej ilości. dla tego części dotyczące rysowania samego interfejsu warto oddzielić od reszty. niektórzy decydują się na utworzenie projektu, w ramach którego jest kilka oddzielnych pliqw, i definicje interfejsu wyrzuca się do takiego oddzielnego pliq. spoko, ale ze względu na spójność, przy takich małych toolach wolę trzymać wszystko w pojedynczym pliq. łatwiej go przesłać do niedoświadczonych użytkowników, wytłumaczyć że to taki plik i już, niż kazać tworzyć jakąś strukturę, czy martwić się, że ktoś kawałek usunął czy nie skopiował. ale to oczywiście kwestia wyboru – ważne, żeby sobie oczyścić kod i możliwie mocno oddzielić logikę od definicji.

nie jest to oczywiście do końca możliwe, bo tak, jak opisywałem poprzednio, logika jest de facto związana z interfejsem – trigger-action. klikniemy guzik to uruchomi się jakiś kawałek. całą sekwencyjność szlag trafia.

ja póki co przyjąłem metodę tworzenia regionów – widać znaczniki #region i #endregion które dzielą skrypt na bloki – tutaj 3 bloki – interfejs, akcje interfejsu i cała reszta. zaleta jest taka, że większość edytorów rozpoznaje ten znacznik i pozwala zwinąć tą część kodu żeby nie pasqdziła widoq.

na koniec

niewątpliwie pisanie skryptów z GUI jest dużo trudniejsze i dużo bardziej czasochłonne. tak, jak przy zwykłym skrypcie 6o-8o% czasu to praca nad logiką działania, tak tutaj, ok. 9o% czasu zjadło mi badanie reguł interakcji między poszczególnymi elementami. ok, uczę się więc potem będzie łatwiej, ale nawet przy tak banalnym skrypciq sprawdzenie czy odpowiednio wyczyszczą się wartości konkretnych kontrolek, czy finalnie ustawiona/przeczytana zmienna jest prawidłowa, czy może pozostało coś z klikania usera, czy guziki są aktywne kiedy trzeba, do tego jak to zoptymalizować, że nie ładowało w kółko po pół minuty…

do tego commandlety Az są… hmm.. nie działają zbyt dobrze q: connect-AzAccount się regularnie [niedeterministycznie] zawiesza po zabiciu okna logowania [cancel], zawiesza się dużo bardziej w Vistual Studio Code, a get-AzContex nie implementuje prawidłowo ErrorAction SilentlyContinue…. żeby tak podać najważniejsze. ogólnie to dość trudna biblioteka do współpracy, bez względu na GUI.

eN.

ITD – garść informacji

już za tydzień ITechDay. zastanawiałem się, jak to będzie wyglądało organizacyjnie, a ponieważ jestem po spotkaniu z organizatorem, garść informacji. jeśli jesteś zarejestrowanym uczestnikiem to pewnie już dostałeś instrukcje, ale IMHO najważniejsze:

 

  • SESJE NIE BĘDĄ NAGRYWANE. ideą jest utrzymanie klimatu konferencji. nie chodzi wyłącznie o wiedzę [choć oczywiście jest priorytetem] ale również o pewną ideę, jaka stoi za takimi eventami – wspólne spotkanie, networking, wymiana myśli na żywo.
  • czy to dobrze czy źle – każdy oceni sam, ale muszę powiedzieć, że przygotowanie całego środowiska wygląda bardzo ciekawie – już samo obejrzenie jak to można zorganizować za pomocą Teams/TLE będzie na pewno ciekawym doświadczeniem.
  • warto również zapoznać się od razu z agendą i ustalić sobie co chcecie zobaczyć – bo równocześnie będzie toczyć się kilka sesji, a jak to w starym sucharze z żabą – raczej się nie rozdwoicie.
  • każdy z uczestników oraz prelegentów dostanie konto konferencyjne – anonimowe logowanie będzie niemożliwe. a to oznacza, że bez rejestracji się nie wbijesz – jeśli więc jeszcze chcesz dołączyć, sugerowałbym się pospieszyć.

w dobie ‘wszystko zdalnie’ uczestniczyłem już w różnych eksperymentach – ten niewątpliwie będzie największym/najbardziej rozbudowanym. jedną z najcenniejszych funkcji konferencji jest networking, i ta formuła ma go umożliwić. podobnie do realnego wydarzenia będą ‘stoiska partnerów’ czyli oddzielne breakout rooms gdzie można będzie zapoznać się ofertami sponsorów i dowiedzieć czegoś na temat ich produktów, hydepark aka “wirtualna pizza” – miejsce, gdzie będzie można swobodnie sobie chatować z innymi i kilka innych ciekawych pomysłów.

…reszta już w rękach uczestników.

PS. a w tym tygodniu virtualny Ignite. tak dla porównania q:

eN.

ITechDay 2o2o

ITD2o’

już 29.IX, [przekornie] ostatni wtorek miesiąca, odbędzie się konferencja ITechDay. również będę miał zaszczyt poprowadzić jedną z sesji. niestety, nadal w atmosferze covidowym, czyli zdalnie, w postaci Teams Live Events, ale co najważniejsze – live. modne ostatnio robi się ogłaszanie ‘konferencji’, które okazują się spreparowanym portalem z sesjami offline…. nie tutaj (:

…bardzo nie lubię sesji zdalnych, brak kontaktu z publiką nie daje feedbacku… ale cóż. znak czasów. mam nadzieję, że ITD21′ odbędzie się już w pełni na żywo. jest opcja komentowania, co prawda z opóźnieniem ~3osec, ale zawsze. przynajmniej nie ma problemu z wejściówkami (;

eN.

OFICJALNA NOTKA

Społeczność WGUiSW.org wraz z Partnerami gorąco zapraszają na kolejną konferencję z cyklu ITechDay.

Wydarzenie odbędzie się w formule online z wykorzystaniem platformy Microsoft Teams.

Tematami wiodącymi konferencji będą:

  • rozwiązania chmury publicznej i prywatnej,
  • aspekty gromadzenia i bezpiecznego przechowywania danych,
  • zapewnienie wysokiej dostępności,
  • automatyzacja zadań w środowiskach IT,
  • analiza i ocena zabezpieczeń infrastruktury IT.

Sesje będą odbywały się równolegle w sześciu ścieżkach tematycznych:

  • Cybersecurity
  • Cloud IT
  • Case study
  • Innovation IT
  • Modern Workplace
  • Data & Dev

Sesje poprowadzą znani prelegenci posiadający bardzo bogate doświadczenie praktyczne poparte wieloma certyfikatami zawodowym.  

Udział w konferencji ITechDay jest bezpłatny.

GUI w skryptach – wstęp

GUI w skryptach?

zasadniczo jestem przeciwny takiemu pomysłowi. celem skryptów jest automatyzacja, a ich największą zaletą jest przetwarzanie potokowe – wyjście jednego skryptu staje się wejściem dla innego. dodanie GUI łamie te zasady – przede wszystkim zakłada interakcję, podczas gdy punktem wyjścia dla skryptu jest podanie parametrów ‘up front’ dające automatyzację danego zadania. 

GUI jest oczywiście niezbędny dla 1szej/2giej linii, ale również pojedyncze zadania łatwiej przeważnie wyklikać. można też wyobrazić sobie rozwiązanie ‘hybrydowe’ [takie modne słowo w dzisiejszych czasach… od paznokci poprzez samochody aż po architekturę IT] – skrypt przyjmuje parametr [np. nazwę pliq wejściowego], a kiedy go nie ma, pokazuje jakiś file-picker czy coś… nie jest to koszerne, ale koniec-końców decyduje zamawiający.

w ostatnim czasie musiałem wrócić do poważnego skryptowania [yyyeeeeey! (= ] właśnie z myślą o narzędziach dla 1szej linii. w zwizq z tym musiałem zmierzyć się z pisaniem pełnego GUI w PowerShell. w związq z tym kilka wniosków i spostrzeżeń.

GUI w PS – możliwości

w oprogramowaniu GUI jestem n00bem. ostatnie aplikacje okienkowe pisałem w Javie na studiach. do tego jeszcze moja ogólna niechęć do takiego pisania… a więc wpis cenny dla tych, którzy są na tej samej drodze. 

są trzy podstawowe metody uzyskania interfejsu dla skryptów:

  • natywne metody PS – jest ich oczywiście niezmiernie mało i są bardzo ograniczone. tak na prawdę ogranicza się do albo sczytywania z linii poleceń [nie bardzo GUI, ale jest interakcja) albo out-GridView – który jest genialną metodą do zrobienia szybkiego ‘pickera’ wartości. dodałbym też tutaj funkcję
    [System.Windows.MessageBox]::Show(MessageBody,Title,ButtonType,Image)
    która natywna dla PS nie jest, ale dobrze uzupełnia możliwości.
  • wykorzystanie obiektu DCOM wscript.shell  który daje możliwość wyświetlenia prostego okienka podobnie do .NET. osobiście mierzi mnie łączenie tak odległych technik jak PS i WScript – IMHO to błąd i zamieszczam wyłącznie żeby napisać: “nie korzystać! to jest legacy crap
  • no i oczywiście pełnoprawne GUI – albo poprzez biblioteki Forms lub WPF. 

dokładniejszy opis w przyszłości, co kiedy jak i z jakim efektem, a póki co

narzędzie dla skryptów na poważnie

zwykłe ISE przestaje wystarczać – nie tyle z powodu samego GUI, co ogólnie tego, że ostatnio piszę więcej. zacisnąłem zęby i po raz kolejny przesiedziałem nad odpaleniem VSCode. VSC niestety jest makabrycznym narzędziem, jednak jego potencjał i choćby możliwości integracyjne są na tyle ważne, że cóż.. płaczę, ale walczę. kiedy to było tylko hobby, odpuszczałem zniechęcony, ale kiedy trzeba bardziej na poważnie, musiałem się złamać

  • VSC jest uniwersalnym narzędziem developerskim. dwa kluczowe słowa: uniwersalne i developerskie – w zasadzie wskazują jego wady. uniwersalne – wszystkiego jest za dużo, 8o% opcji jest zbędne przy pisaniu w PS. po instalacji dostajemy coś, czego do pisania w PS nie da się używać – a więc czeka nas czytanie serii artykułów i wpisów na forum, które pluginy zainstalować, jak skonfigurować, które z tysięcy opcji jak ustawić żeby uzyskać jakiś sensowny efekt.
    to co kiedyś było potęgą produktów MS – integralność i trzymanie się pojedynczych standardów – załamało się wraz z “powszechną linuxyzacją”. dziś wszystko trzeba wybrać z pośród dziesiątek lub setek różnych dodatków i zaczynają się problemy że ‘ten dodatek jest szybszy a tamten ma taką opcję, a inny gryzie się z tamtym ale ma tą funkcję..’ .. i tak zaczyna się żmudna żonglerka dobrania sobie zestawu pluginów tak, aby mieć maksymalnie dużo wymaganych funkcji, równocześnie nie przeciążyć środowiska zbytecznymi śmieciami …
  • …które doprowadzą do niestabilności. podstawowe zastrzeżenie jakie mam do VSC to niestabilność, a zwłaszcza inteliSens, który regularnie przestaje działać w trakcie pisania. skrót “alt-ctrl-p, reload” już mi wszedł w krew /: [muszę poszukać pluginu, który mi doda tą operację pod jednym guzikiem q:]. o ile ISE zawieszało się w bardzo szczególnych przypadkach [np. korzystając z commadletów Exchange] o tyle VSC wywala się jak archetypiczny open source. poprawki wydawane typowo agile – czyli update za updatem i trzymanie kciuków, czy dziś będzie się wywalać się bardziej….  welcome to open source .. and agile.    

czemu warto pocierpieć? przy pewnej wielkości czy skomplikowaniu skryptu, nie mówiąc o projekcie w którym tych skryptów jest wiele, ale nawet kiedy po porostu trzeba przy nich popracować więcej – ISE to za mało. lepsze wyświetlanie składni, czy masy skrótów klawiszowych, znacznie przyspieszają pracę. integracja z repo, projekty… jest wiele dodatków, bez których byłoby więcej ręcznej pracy – czyli to co jest wadą, przy zainwestowaniu czasu, staje się podstawową przewagą.

jeśli więc czeka cię przesiadka – zarezerwuj sobie przynajmniej tydzień nieskończonej cierpliwości. będzie za to nagroda w postaci dużych możliwości i jeszcze większego potencjału. jeśli jednak nie korzystasz z repo, piszesz hobbystycznie lub okazjonalnie – ISE to wszystko co potrzebne i szkoda czasu i stresu. 

pisanie GUI

niestety VSC nie pomaga zbytnio w pisaniu GUI. może są dodatki, których jeszcze nie znalazłem, ale ogólnie – oprogramowanie GUI w edytorze nie-wizualnym to porażka. kilka elementów i robią się setki linii kodu ciężkie do ogarnięcia. ustawianie guzików zmieniając ich położenie wartościami X/Y na czuja – makabra. interfejs najlepiej się rysuje w interfejsie, dla tego najsensowniej jest mieć coś wizualnego. chciałoby się powiedzieć Visual Studio… huh, ale VS do pisania skryptów PS, to jak instalacja Exchange on prem w pełnej redundancji do wysyłania kilq emali. 

w skrócie – cały czas jestem w trakcie poszukiwania jakiegoś lekkiego designera interfejsu. te, które testowałem online były … jak to aplikacje online – siermiężne i ograniczone. 

forms vs UWP vs WPF

już sam wybór tego w czym ten interfejs ma być napisany nie jest łatwy. formsy wygrywają ilością dostępnych przykładów, UWP [chyba] umiera, WPF niby jest trendem, nowsze, nowocześniejsze i bardziej uniwersalne… ale czy przyszłościowe? no właśnie – nawet po przeczytaniu kilq artów, jeśli nie siedzi się w temacie, sam dobór biblioteki nie jest trywialny. jeśli się uczyć, chciałoby się nauczyć czegoś, co choć przez kilka lat się przyda. a to w obecnym tempie zmian niełatwe zadanie. 

osobiście póki co zdecydowałem się na formsy – stare, dobre, oklepane, dużo przykładów, a póki Microsoft nie zrezygnuje z Windows na rzecz jakiejś hybrydowej dystrybucji [chciałoby się powiedzieć Lindows, ale to już było] , zgromadzona wiedza powinna żyć przez jakiś czas.

zmiana logiki

ciekawym aspektem jest zmiana paradygmatu całej logiki działania. skrypty, poniekąd z samej definicji skryptu – przetwarzane są sekwencyjnie linia po linii. tak też logika pisania jest ‘liniowa’. GUI to z kolei ‘rozproszona logika’ pozaczepiania pod elementy interfejsu. całość nie jest już jak opowiadanie:

begin { początkiem }
process { rozwinięciem }
end { i końcem }

w zamian staje się fragmentarycznym kodem, sterowanym akcjami z kliknięć czy innych list. dla skrypciarza z krwi i kości to jest inny świat. dziwny i nie do końca logiczny. 

GUI + skrypt

na tym etapie nie mam jeszcze wyrobionych ‘best practice’ więc poszuqję. jednym z pomysłów było zadziałanie tak, jak to przez pewien czas projektował Microsoft [i co mi się bardzo podobało] – interfejs służył do zebrania informacji, wizualizacji elementów, ale ostateczna akcja to był po prostu skrypt uruchomiony z parametrami, których wartości były zebrane z interfejsu.

takie podejście jest świetne jednak w momencie kiedy pisze się duże, rozbudowane narzędzie, aplikację pozwalającą na wykonanie wielu zadań. jednak drobny tool, którego celem jest właśnie ograniczenie wyborów i dostosowanie do konkretnego zadania w konkretnym środowisq powoduje, że rozdzielenie na dwa niezależne skrypty [jeden to GUI do zebrania parametrów, drugi do wykonania akcji] tworzy dużą nadmiarowość. ponadto takie podejście choć ‘ładne’ i logiczne, utrudnia uruchomienie osobom, które tych skryptów się już i tak boją. to te niuanse – łatwiej komuś nieqmatemu przesłać jeden plik do uruchomienia, niż kilka, z opisem jak zrobić bibliotekę, czy jak przygotować środowisko. w regularnej aplikacji załatwia to instalator, przy skrypcie to już nie takie proste. 

z kolei zaletami oddzielenia GUI od logiki jest łatwiejsze panowanie nad samym wykonaniem, no i dla osób, które GUI nie potrzebują – od razu jest narzędzie. większa uniwersalność. mam nadzieję pokazać przykłady za jakiś czas.

praktyka pokaże który sposób wygra, choć widzę coraz więcej zalet rozbicia tego monolitycznego podejścia na rzecz bardziej uniwersalnej metody…

kompromis

skoro skrypty nie są do pisania GUI, przesiadka jest trudna, to czemu po prostu nie zacząć pisać np. w C#? 

proste: mimo-wszystko łatwiej nauczyć się oprogramowania samych Formsów, niż całego języka. na drugi dzień byłem w stanie narysować prosty interfejs, podpiąć logikę i zbudować jakiś działający skrypt. a to dla tego, że cała faktyczna logika, aktywna część działania była tym, co znam, w postaci commandletów. nauczenie się napisania tego w C# i poznanie całej specyfiki samego języka, zajęła by znacznie więcej czasu. choć podobny do PS – jest czyś zupełnie innym. no i podstawowa rzecz – nie zamierzam być developerem [może kiedyś, hobbystycznie] a tego rodzaju zadania są ‘szybkim wsparciem’, a nie moim codziennym zajęciem. póki co nauka C# byłaby stratą czasu. 

jak mawiają: ‘życie składa się z kompromisów’. kompromisem jest tutaj wyważenie efektu i czasu. pozostają zalety skryptu: kod nie jest kompilowany, łatwo go przeczytać a w razie potrzeby zmodyfikować ‘gdziekolwiek’, bo bez konieczności rekompilacji, commandlety dają obszerne biblioteki o olbrzymich możliwościach, a równocześnie można dopiąć kawałek GUI – i to wszystko w bardzo krótkim czasie.

może Frankenstein, ale żywy i myślący. 

eN. 

 

wf-refresh

w-files’om strzeliła w tym rokq piętnastka… czas w IT liczy się trochę inaczej – 15 lat to kilka epok. jeśli przypomnieć sobie jak wyglądał ten świat w 2oo5… trochę sobie przypomniałem przeglądając stare artyqły… długa droga to była i wyboista ale jakże emocjonująca.  praca (i po części hobby) zajmuje większość życia – więc ten nLog, choć przez pryzmat technologii i zawodu, ale opowiada ciekawą historię – zarówno o ewolucji technologii jak i mnie samego.

<chwila nostalgii>

wszystkiego naj, wfilesowicze! z tej okazji drobny refresh strony – lżejszy, kompatybilny z aktualnymi wersjami i wyświetla się prawidłowo na mobilu… które w czasach tworzenia poprzedniego szablonu nie służyły za codzienne narzędzie do oglądania treści w Internecie. no i bezpieczniejszy. mam nadzieję, że wytrzyma następną epokę.

pro publico bono.

eN.

 

nazwa plików wyjściowych – zabawa regex

nazwy pliqw

nazewnictwo pliqw wyjściowych wydaje się sprawą trywialną. w najprostszej wersji, wygodnej zwłaszcza dla pliqw tymczasowych można to zrobić tak:

[System.IO.Path]::GetRandomFileName()

generuje to unikalne nazwy pliqw z uniknięciem konfliktów, tego pokroju: “4toqskhi.qbk”.

ale w przypadq logów lub wyjścia, które będzie dalej wykorzystywane, pliki muszą mieć bardziej konkretne nazwy, i pomagać nie pogubić się w przypadq wielu uruchomień i konieczności kontroli co-do-czego. większość skryptów, odruchowo, zaopatruję w funkcję logowania, a sam plik logu, aby wiadomo było czego dotyczy, ma nazwę skryptu:

$logFile="_$( ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName )-$(Get-Date -Format yyMMddHHmm).log"

dzięki temu logi zaczynają się podkreślnikiem (wygodne sortowanie i wyróżnik), zawierają nazwę skryptu (wiadomo czego log dotyczy) oraz daty (dzięki czemu łatwiej zorientować się, o który chodzi). np tak:

skrypt: new-CloudUser.ps1 

log: _new-CloudUser-202008051001.log

ale log to jedno, a wyjście do dalszego przetwarzania to inna para kaloszy. podstawowym typem pliq z jakim pracuję to CSV – głównie ze względu na łatwość w dostarczaniu wyników dla biznesu (w postaci xlsx) oraz oczywiście – niezmierną łatwość w pracy z tym formatem. okazuje się, że w wielu scenariuszach, przy których plik jest przetwarzany przez biznes i ma do niego z powrotem trafić po obróbce, najlepiej, żeby nazwa odzwierciedlała nazwę pliq wejściowego. a przy kilqkrotnym przetwarzaniu powinna być jakaś inkrementalna wartość liczbowa. można to oczywiście osiągnąć na wiele sposobów, ale lubię eleganckie sztuczki, wykorzystujące fajne mechanizmy – np. takie jak regex.

lekcja poprawnego wyrażania się

choć z wyrażeń regularnych korzystam od bardzo dawna i wkładam wiele wysiłq, żeby je okiełznać, to nadal pozostają dużym wyzwaniem. są IMHO jedną z najtrudniejszych do opanowania technik i nadal czuję się n00bem, nie potrafiąc ogarnąć backreferences czy wykorzystania pewnych elementów w ramach przetwarzania regex. to jest świetna gimnastyka dla umysłu, więc często tworzę regexy tak, jak niektórzy grają w sudoq. oczywiście przy wielu zastosowaniach lepszej metody ani bardziej wydajnej nie ma. inaczej trzeba by pisać setki pozagnieżdżanych IFów czy switchy, a w niektórych przypadkach nawet to nie da rezultatu.

Ale często chodzi o zwykły “challange” – bo jak się czegoś nauczyć inaczej, niż korzystając z tego?

a więc w celach edukacyjnych, przeanalizuję taką funkcję:

$fileInput=get-Item $inputCSV
if($fileInput.BaseName -match '-prepped(?<inc>\d{0,2})') {
    $outputCSV=$fileInput.BaseName -replace '-prepped\d{0,2}-[\d]+',"-prepped$( if($Matches.inc) { (([decimal]$Matches.inc)+1).toString("00") } else { "02" } )-$(Get-Date -Format yyMMddHHmm).csv"
} else {
    $outputCSV="{0}-prepped01-{1}.csv" -f $fileInput.BaseName,(Get-Date -Format yyMMddHHmm)
}

założenie: chcę aby przetworzony plik miał suffix ‘prepped‘ z numerkiem dopełnionym zerami, wskazujący na liczbę przetworzeń.

algorytm jest taki:

  • biorę nazwę pliq wejściowego – np. ‘myData’
  • nie wiem czy to pierwszy przebieg, więc najpierw sprawdzam czy nazwa pliq zawiera już suffix – “IF()”.
  • trochę nie po kolei – ale zacznę od ‘nie, nie zawiera’, ponieważ tu sprawa jest prosta – po prostu tworzę nazwę “<nazwaPliqWejsciowego>-prepped01-<dataPrzetworzenia>.csv” – co widać po ELSE
  • ciekawszy jest przypadek ‘tak, zawiera’ – jak wyciągnąć numer i go zwiększyć?

tutaj w sukurs przychodzą wyrażenia regularne. w PowerShell można stosować je niemal wszędzie, a każdym razie wszędzie tam, gdzie używamy funkcji ‘match’ lub ‘replace’ (ale pozwala na to również wiele poleceń). klauzula ‘if’ zawiera:

$fileInput.BaseName -match '-prepped(?<inc>\d{0,2})'

a ciekawym fragmentem jest oczywiście “(?<inc>\d{0,2})“, który oznacza:

  • nawiasy () to tzw. capture group. to, co zostanie dopasowane do szablonu opisanego wewnątrz nawiasów, zostanie zapisane jako zmienna w tablicy wyniqw. w PowerShell wyniki dopasowań przetrzymywane są w automatycznej zmiennej $Matches, będącą tablicą dopasowań.
  • konstrukcja “?<inc>” nadaje temu dopasowaniu nazwę (‘named capture group’) . w ramach zmiennej $Matches wyniki przechowywane są jako tablica, więc aby wybrać konkretny element, nie mogąc przewidzieć ilości wyników czy ich kolejności, najlepiej nadać wynikowi nazwę.
  • “\d” oznacza dowolną cyfrę. można to również zapisać jako “[0-9]”
  • {0,2} oznacza liczbę wystąpień poprzedzającej definicji – tu: cyfry.

czyli ciągi spełniające definicję szablonu i zwracające ‘True’ to np:

  • “mojanazwa-prepped-cośtu.csv”
  • “mojanazwa-prepped1-cośtu.csv”
  • “mojanazwa-prepped01-cośtu.csv”
  • “mojanazwa-prepped23-cośtu.csv”

w zmiennej $Matches, pod nazwą ‘inc’ będzie przechowywana liczba… a w zasadzie ‘ciąg znaków składający się z cyfr’ bo będzie to [string]. chyba, żeby nie. bo jeśli mamy tylko “-prepped-” to element ‘inc’ się nie pojawi (będzie $null) – czyli w pierwszym prezentowanym przykładzie, wartość “$Matches.inc” będzie $null.

po przejściu ‘IF’ wykonywany jest ‘replace’, który również korzysta z regex. tutaj pojawia się dodatkowo “[\d]+” i nie ma nawiasów okrągłych:

$outputCSV=$fileInput.BaseName -replace ‘-prepped\d{0,2}-[\d]+‘,”-prepped$( if($Matches.inc) { (([decimal]$Matches.inc)+1).toString(“00”) } else { “02” } )-$(Get-Date -Format yyMMddHHmm).csv

ciąg spełniający szablon opisany pogrubioną czcionką, zostanie zastąpiony wyliczeniem, opisanym na pomarańczowo. a co się tam dzieje?

  • nawiasy kwadratowe ‘[]’ mają zgoła odmienną funkcję niż okrągłe. ich celem jest określenie dopuszczalnego zbioru kryteriów. np. [abc] oznacza, iż dowolna POJEDYNCZA litera spełni warunek, jeśli będzie literą a, b lub c. czyli dla wyrażenia regex ‘[abc]’ dla słowa ‘żaba’, będą trzy pozytywne wyniki – ‘a’, ‘b’ oraz ‘a’.
C:\_scriptz> [regex]$rxz='[abc]'
C:\_scriptz> $rxz.Matches('zaba')|select index,value

Index Value
----- -----
1 a
2 b
3 a
  • plus ‘+’ oznacza, że liter musi być jedna lub więcej. standardowe wyszukiwanie jest ‘zachłanne’ [greedy], czyli zwróci maksymalny ciąg spełniający warunek. czyli ‘[abc]+’ zwróci maksymalnie długie ciągi znaków, składający się z liter a, b oraz c
PS C:\_scriptz> [regex]$rxz='[abc]+'
PS C:\_scriptz> $rxz.Matches('zaba')|select index,value

Index Value
----- -----
1 aba
  • w tym szablonie nie ma zwracanej grupy (nawiasów okrągłych) … chciałbym ‘przechwycić’ wartość liczbową po ‘prepped’ aby ją zwiększyć, więc powinna być… ale to za chwilę.

co się dzieje w funkcji generującej wynik?

"-prepped$(
    if($Matches.inc) {
        ( ([decimal]$Matches.inc)+1 ).toString("00")
    } else {
        "02"
    }
)-$(Get-Date -Format yyMMddHHmm).csv"

ciąg spełniający opisane wcześniej warunki, zostanie zastąpiony:

  • ciągiem ‘-prepped’
  • następnie jest typowe dla PowerShell wyliczenie zmiennej – “$( <kod> )”
  • (if) wyliczenie zależy czy znalezione zostały liczby, czyli czy $Matches.inc istnieje czy jest $null. jest to nieco dziwna konstrukcja tutaj, ponieważ zmienna $Matches przechowuje wyniki… z poprzedniego wyszukiwania – tego, który był w IFie, tego z nawiasami ‘()’ – to tam tworzony jest element ‘inc’ i dla tego nie ma nawiasów w samym ‘replace’. co prawda istnieje możliwość wykorzystania wyników dopasować z obecnie przetwarzanego  ‘replace’, ale dopiero w wersji 6 PowerShell. dla wersji 5 i niższych, rozwiązanie jest mniej eleganckie, a takie wersje są na większości serwerów…
  • jeśli jakiś ciąg liczbowy jest, to trzeba go zmienić w liczbę [wymusić interpretację jako liczba] i zwiększyć o jeden: [decimal]$Matches.inc+1 . następnie chcę mieć pewność, że zostanie dopełniony zerami – czyli np. ‘3’ stanie się ’03’. to realizuje funkcja toString(“00”)
  • (else) jeśli liczby nie ma, czyli jest samo ‘prepped’, to dodaję “02” jako drugi przebieg.
  • no i oczywiście wstawiam aktualną datę przebiegu

już sam fakt tego, ile trzeba zrobić opisu, żeby wyjaśnić malutkiego regexa pokazuje jaką kryje w sobie moc… a więc zamiast sudoq – proponuję przerobić sobie jakieś wyszukiwanie na wyrażenie regularne (:

eN.

MFA – dodatek czy konieczność?

zgodnie z zapowiedzią kolejny fragment arcyciekawego wywiadu z d0m3lem. to ważny temat, więc warto o nim porozmawiać…

Czy MFA jest ważne?

<MG> W kontekście architektury zabezpieczeń, chciałbym rozszerzyć to pytanie. W ogóle jakie są największe teraz wyzwania, z którymi mierzycie się w całej tej działce Identity? Czy to jest brak wiedzy? Czy jednak te ograniczenia technologiczne, czy ten dług technologiczny?

<d0m3l> Ludzie nie chcą korzystać z MFA.

<MG> Czyli jednak interface białkowy to jest największe wyzwanie?

[…]

<d0m3l> Tak, generalnie kwestia jest taka: Spytaliśmy naszych kolegów z Google’a, jaką mają adopcję MFA? Okazuje się, że w momencie, kiedy jesteś goniony przez atakujących, przez hackerów to jest tak, jak bycie gonionym przez stado wilków. Jak Cię gonią wilki to nie chodzi o to, żeby prześcignąć wilki. To chodzi o to, żeby prześcignąć najwolniejszego w tłumie. Więc w momencie, kiedy masz włączony SMS jako jedyne MFA na Twoim koncie, na Twojej usłudze, gdziekolwiek, to Cię broni przed 1oo% zautomatyzowanych ataków. Czyli jak jest scriptkidi albo narzędzia tych atakujących hackerskich grup narodowych takich jak Iran, Somalia, Nigeria, jest parę takich bardzo fajnych organizacji, które próbują się dostać do Twojej poczty. Jeżeli masz SMS jako jedyne MFA na swoim koncie, jakikolwiek skrypt, oprogramowanie jakie mają, żeby Cię zbruteforce’ować, zespray’ować jest zablokowane. Jeżeli targetują Ciebie, jako osobę koszt zhackowania Ciebie rośnie z 70 centów do 70 dolarów i udaje im się to w 40% przypadków.

<nExoR> To jeszcze tylko jedna rzecz apropos tego MFA i statystyk, chciałem zaznaczyć, że strasznie kłamiecie. Bo nie potraficie zliczać MFA wymuszonego Conditional Accessem, gdzie na przykład w firmach administratorzy to np. 2% w stosunku do użytkowników. Administratorzy mają wymuszone MFA, cała reszta, czyli 98% ma Conditional Accessem. Co mówi Microsoft? 98% ludzi nie ma włączonego MFA.

<d0m3l> W tej chwili z mogę Ci powiedzieć dokładnie ile jest ludzi, którzy mają MFA. To jest 33% użytkowników w Office 365 podało jakiś sposób weryfikacji, że można ich w jakiś sposób wymusić.

<nExoR> Czyli to jest nie na podstawie włączonej opcji, że musisz mieć MFA, tylko to jest na podstawie danych, które zostały podane do kont?

<d0m3l> Tak.

<nExoR> To jak jesteśmy przy tym od razu. Czy będzie jakaś usługa, jakiś sposób zabezpieczenia, bo jest taka dziura w MFA przy onboardingu. Bo jak założysz konto, włączysz MFA, masz provisioning użytkowników to nadal do kogo pierwszego trafią Credentiale, ten sobie MFA ustawia. No i teraz wiadomo, że jest jakiś duży procent użytkowników, którzy, no wiadomo są takie cienie, ktoś nigdy nie przyszedł do pracy albo nie używa konta i one sobie wiszą. Jak zhackujesz takie konto to od razu sobie ustawiasz MFA, i jest jakby podwójnie uwierzytelniony w tej domenie i przez to jeszcze bardziej zhackowany. Czy tutaj można się spodziewać jakiegoś wyjścia naprzeciw? […]

<d0m3l> Generalnie są 2 sposoby. Sposób proceduralny i sposób technologiczny. Sposób proceduralny, pomijanie MFA ze względu na lokalizację, jedno z najgorszych zaleceń, jakie Microsoft kiedykolwiek wydał. MFA  powinno być też wymuszone w Corpnecie. MFA musisz zrobić zawsze. Jeden prompt per użytkownik, per urządzenie, per zmiana hasła, koniec kropka. To, że spiąłeś się VPNem nie powinno Cię wykluczać z wymagania MFA. To jest Zero Trust. To jest proceduralnie. Drugi to jest taki, że jest funkcjonalność w Conditional Accessie, która mówi, że żeby się zenrollować do MFA musisz spełniać wymagania. Jest takie coś, co nazywa się User Actions jako warunek w Conditional Accessie, gdzie możesz powiedzieć: “Żeby zenrollować się do MFA musisz być na urządzeniu, które uważam za zaufane” albo “Musisz być w konkretnym zakresie adresów IP”.

<nExoR> Zakresy IP to w ogóle są trochę od czapy te polityki z zakresami IP, bo połowa firm używa Proxy, Application Proxy czy innych mechanizmów przekierowujących ruch i wychodzenie ze stałego IP, zwłaszcza w świecie mobilnym, to jest w ogóle jakieś nieporozumienie.

<d0m3l> Kwestia jest taka, że nie ma wystarczającej ilości technologii na świecie, żeby naprawić gówniane procesy. Nie ma. Jeżeli Twój proces jest niewystarczający to możesz się bawić w hocki-klocki. Takie podatności o jakich Ty mówisz, że hacker albo zły aktor dostanie się i uwierzytelni zamiast użytkownika zdarzają się 2 w miesiącu na całą skalę Office 365. Na 320 milionów użytkowników. 2 w miesiącu. Oba z nich są łapane przez zwykłych użytkowników, którzy zostają wykopani z konta w momencie, kiedy ktoś zamiast nich dokona poświadczenia. Więc takie reaktywne wyłapywanie działa bardzo dobrze pod warunkiem, że nie masz wykluczeń MFA. Okazuje się, że najbardziej popularną polityką Conditional Access jaka istnieje jest: MFA dla wszystkich, poza zaufaną lokalizacją, czyli jeżeli jesteś na Cornplecie albo na Wi-Fi, żadnego MFA. Czyli Pani Józia, która siedzi w biurze i nigdy nie dostaje się do maila poza biurem, nigdy tego MFA nie zobaczy.

<nExoR> Tak, no wtedy go nigdy nie skonfiguruje, czyli jest niebezpieczne. No właśnie, czyli to taki drugi scenariusz.

<d0m3l> Dlatego jeżeli zły aktor dostanie hasło i spróbuje zrobić zarejestrowanie tego MFA, możesz to Conditional Accessem ograniczyć. Mówisz, że ktoś, kto ma hasło Pani Józi, żeby zarejestrować jej MFA musi być na urządzeniu, które jest dopięte do naszej domeny, musi być Hybrid Joined. I tyle.

[…]

<d0m3l> MFA musi być włączone zawsze. Ten link, który pokazałem, M365 Golden Config. Użytkownik przychodzi pierwszego dnia w pracy. Tego pierwszego dnia w pracy użytkownik musi potwierdzić, że ma dostęp do jakiegoś MFA. Problemem zaczyna się robić wdrożenie gdzie masz 23.ooo użytkowników, którzy jeszcze nie podali danych. MFA ma 1o% Faliure Rate przy rejestracji. 1o% użytkowników będzie Ci krzyczało, że nie umieją zeskanować kodu QR na ekranie.

[…]

<MG> Czy MFA jest, zadam takie pytanie znowu z wyższego poziomu, czy MFA jest idealnym zabezpieczeniem? Jak nie, to czego mu brakuje?

[…]

<d0m3l> Powiem tak: Grzesiek pytał o te statystyki Googlowe. Statystyki są prosto z konferencji, która nazywa się “Stripe”. Google mówił, że jedyne idioto-odporne, bo MFA da się zfishować. Fishing, czyli ktoś wysyła Ci maila, klikasz link i podajesz Twój login, hasło i MFA. MFA da się zrobić fish. Bez problemu, potem mam dostęp do Twojej poczty forever and ever, dopóki nie zmienisz swojego hasła. Jedyny sposób, który takiemu atakowi zapobiegnie to używanie metod poświadczeń, które są oparte o sprzęt. Czyli: Hello for Businnes – niefishowalny, Tokeny FIDO – niefishowalne. Dlatego, w momencie kiedy masz hasło i coś po haśle dopóty, dopóki to będzie aktywnym MFA, dopóty będziesz miał możliwość, że ktoś je zhackuje. Do wtedy, gdy będziesz klikał w te linki fishingowe. Nie da się zrobić, żeby mniej niż 20% Twoich użytkowników klikało w linki fishingowe. Możesz robić banery, ostrzeżenia itd.., 2o% ludzi kliknie w link, który się im pojawi w skrzynce odbiorczej. SANS Institute zrobił badania. 2o% to jest podłoga. W Microsofcie 35% ludzi jest fishowalnych, wewnętrznie u nas w firmie, bo jesteśmy przyklejeni do maila 24/7. 35% ostatnia kampania wewnętrzna fishingowa, testowa.

<MG> Czyli trzeba ogólnie całkowicie ominąć możliwość tego fisha, czyli tak, jak mówiłeś, Tokeny FIDO na przykład.

<A> Ale pamiętaj, że jeszcze masz drugą możliwość, czyli na przykład “o, tu jest taka fakturka”; “Ty, słuchaj, nie chce mi się w niczym otworzyć, zobacz co to”.

<d0m3l>     No. „Każdy burdel da się ogarnąć, tylko proszę dane do faktury”, nie? Ale to już jest chyba trochę taki Social Engeneering, prawda?

End Of Quote

oryginał rozmowy tutaj.

o ważności MFA jestem świadom i zawsze jest to pierwsza rzecz jaką sprawdzam – czy jest włączone. muszę przyznać, że zezwolenie na brak MFA kiedy się jest w biurze wydawało mi się zawsze dobrym pomysłem. teraz nie jestem już taki pewien (; pozostawiam do oceny czytelnikom.

eN.

czy Microsoft słucha użytkowników?

pasjonaci IT

nie tak dawno zapraszałem na spotkanie z Danielem Stefaniakiem, IAM Product Manager w Microsoft, pracującym w samym sercu tego, gdzie powstają usługi M365 – w Redmond. pełne nagranie z tego spotkania można obejrzeć na YT na kanale “Pasjonaci IT” . ilość wiedzy jaka posypała się podczas tych 1,5h okazała się olbrzymia. ponieważ nie każdy lubi słuchać, niektórzy nadal lubią czytać – zamieszczę kilka ważnych informacji jakie padły podczas tej rozmowy. dziś na smaka wrzucę fragment dotyczący User Voice – czy to tylko taki ‘anti-stress button’ żeby ludzi mogli wylać swoje frustracje, czy faktycznie Microsoft przygląda się tym wpisom, analizuje i zmienia swoje plany?

poniżej fragment transkryptu, który może być nieco zmodyfikowany dla wygody czytania.

UserVoice

  • <nExoR>   […] to ciekawe, co powiedziałeś. Wiem, że uservoice funkcjonuje całkiem fajnie od jakiegoś czasu, natomiast jak to realnie wygląda procentowo? No bo uservoice – uservoice’em, natomiast musi być jakaś road mapa odgórna. czy jesteś w stanie określić na ile procentowo jest to uservoice, na ile odgórne ustalenia? np. uservoice to jest 15% całego rozwoju, a 85% to jest roadmapa, czy może jest odwrotnie, że właśnie 15% to jest jakaś odgórna wizja, a 85% to jest to, co ludzie chcą? Jak byś to mniej więcej określił?
  • <d0m3l>  W mojej działce, w Azure Active Directory [IAM], uservoice to jest około 15 – 2o% . Tak naprawdę chodzi o to, że w tej chwili Azure AD to jest system, który wiezie ze sobą 32o milionów użytkowników codziennie, więc to nie jest taki stateczek, który da się zawrócić z dnia na dzień. Więc w tej chwili korzystamy z uservoice’ów, albo z pracy z największymi klientami z Fortune 5oo, którzy na nas krzyczą: “Dlaczego to, kurka, tak nie działa? Bo próbuję zrobić XYZ, ale Wy mi nie dajecie takiej możliwości”. więc szturchamy na prawo i lewo, żeby ten stateczek popłynął tam, gdzie klienci będą chcieli na niego wsiąść, bo na pewno nie stoi w miejscu. Więc z uservoice te rzeczy, które mają powyżej 1oo głosów, czy tam 15o, muszą być wciśnięte w road mapę na najbliższe 12 miesięcy. Nasza Pani Vice President powiedziała, że tak ma być, koniec kropka: “Właściciele funkcjonalności wymyślcie, jak zaadresować uservoice’a”.
  • <MG>        1oo – 15o głosów to nie jest taki duży próg…
  • <domel>     W Azure AD to jest bardzo wysoki próg.
  • <nExoR>   Naprawdę? Tak mało jest uservoice’ów?
  • <domel>     Tak. Największy uservoice ma 13oo głosów.
  • <nExoR>   I na co jest?
  • <domel>     Rozdzielenie albo połączenie Microsoft Account i kont Azure AD. Bo, jak pamiętacie LifeID rozdzieliło się od Office 365 w jednym momencie i teraz się okazuje, że  jak masz LifeID i konto w Office 365 na ten sam adres e-mail to masz ten głupi label pod tytułem “konto organizacyjne vs. konto prywatne“, więc ludzie na to bluzgają strasznie. Drugi w tej chwili to jest chyba cel w Service Password Reset bez dostępu do kontrolera domeny, więc to są dwa takie największe. Teamsy mają dziesiątki tysięcy uservoice’ów [bo to frontend’owa aplikacja]

End of Quote

swoją drogą sprawdziłem i są jeszcze dwa requesty:

  • nested groups: ~18oo głosów
  • tokeny B2C zawierające członkostwo użytkownika: ~15oo głosów

i to faktycznie max. a Top Ideas dla Teams ma ponad 55k. to pokazuje, różnicę backend vs frontend q:

w świetnym dziele filozoficznym, post-humanistycznym “Po piśmie“, Jacek Dukaj pokazuje jak zmieniała się ludzkość na przestrzeni dziejów – z kultury mówionej, teraz przez literacką… a w przyszłości w przekaz natychmiastowy. ludzie już dziś wolą obejrzeć niż przeczytać, podcasty i filmy zastępują książki, video zastępuje instrukcje i poradniki…

jestem dinozaurem – ja wolę czytać. albo może to technologia jeszcze nie dorosła po prostu – bo jak wyszukać jakiś interesujący fragment? jak wyszukać interesującą frazę w 1,5h materiale? albo jak ‘przelecieć wzrokiem’ video? czasem mniej ciekawe fragmenty artu można po prostu szybko ominąć, przy video trudniej. dla tego  w najbliższych dniach dodam jeszcze trochę fajnych informacji z naszej rozmowy – bo czasem tygodnie, a nawet miesiące surfowania, nie dadzą takich wyniqw.

d0m3lu – dzięki [twoje konto cały czas jeszcze jest na w-files q: ]

eN.

pasjonaci IT – rozmawiamy z Product Manager Identity

Michał Guzowski rozpoczął ostatnio inicjatywę dla pasjonatów IT – ot po prostu spotkać się raz na tydzień i porozmawiać na tematy związane z IT. w najbliższy wtorek do spotkania dołączy Senior Product Manager of Identity & Access Management, prosto z Redmond. I *nie będzie* to spotkanie w języq angielskim – ponieważ jest nim Polak (: można więc będzie w przystępny dla każdego sposób dowiedzieć się kilq ciekawostek, zarówno dotyczących produktów, ale również samej kariery w Microsoft…

eN.

M365 jako platforma – inna perspektywa

kolejne spojrzenie na ‘platformę’ – w dwóch kontekstach. po pierwsze – bezpieczeństwo, po drugie – konsekwencje ‘on-premowego myślenia’. w sumie to odwrotnie, bo zaniechania z w prawidłowej konfiguracji bezpieczeństwa wynikają głównie z faktu, że M365 nie jest prawidłowo rozumiane. bo cały czas poqtuje ‘stare myślenie’. taka oto anegdota [prawdziwa], która powinna dobrze zobrazować, co mam na myśli…

dzień dobry, my po Teamsy….

niedawno, po wybuchu pandemii, duża firma postanowiła zwiększyć możliwości pracy z domu [#WFH]. więc firma chce wdrożyć Microsoft Teams. *tylko* Teams…

[parafrazując] “no bo przecież takie Teamsy, to zainstaluje się i już – ludzie mogą sobie korzystać. mamy jakieś licencje i to w ramach EA nawet O365 E3 i to całkiem sporo. nie chcemy od razu dla wszystkich tylko małymi kroczkami – odpalimy dla np. 5o osób jako PoC a potem dla reszty organizacji. a jakieś dodatki typu skrzynki czy OneDrive to może potem. na razie chcemy szybko [i tanio], żeby skorzystać z możliwości tej wspaniałej pracy grupowej, jaką daje Teams”…

khmmm… no i to takie “onpremowe myślenie”. zupełnie wszystko do góry nogami. jeśli nie wiecie o czym mówię – to znaczy, że jeszcze musicie się w M365 wgryźć… jakie błędy zostały popełnione w tym rozumowaniu? zadajmy klientowi kilka pytań i co się okaże:

  • jest już AD. oczywiście powinno być SSO, a w przyszłości bardziej wykorzystać usługę. czyli trzeba zacząć od zaprojektowania tożsamości hybrydowej, synchronizacji, określić zasady synchronizacji – nawet jeśli początkowo synchronizowałoby się tylko kilka osób, to trzeba zrobić pełny projekt. firma niemała, AD niemałe, a wiadomo – jak się zajrzy do szafy [AD] to zaczną trupy wypadać [cała historia i nakładające się modele zarządzania]. trzeba jakieś serwery dla ADConnect postawić, redundancja, ustalić metodę uwierzytelnienia – w końcu to ma być produkcja, jak się źle poustala, to potem będzie ciężko to zmieniać… to tak w ramach rozgrzewki…
  • jest Exchange on-premise. ale Teams korzysta ze skrzynek pocztowych. nie dość, że trochę ciężko przewidzieć co by się stało jak by to tak po prostu rozdzielnie potraktować [znaczy duplicate-mailbox by się stało], ale klient wspomniał, że będzie raczej chciał usługę mocniej utylizować w przyszłości. a to oznacza hybrydę Exchange – i znów projekt i DNSy i mailflow i reguły na FW itd….
  • jest oczywiście i SfB on-premise… czyli musi być współdzielony SIP domain, hybryda SfB … i znów – trzeba to zaprojektować, wdrożyć ….
  • przetwarzane są informacje wrażliwe a firma podlega licznym normom i wymaganiom bezpieczeństwa – a więc trzeba skonfigurować polityki bezpieczeństwa dla wszystkich komponentów, ustalić co użytkownicy mogą a czego nie mogą … o tym więcej za chwilę, ale już widać – że to nie zadanie na 5 minut tylko ciężki projekt.

w dużym skrócie – nie ma pojęcia ‘tylko Teamsy’… no ok, da się ‘tylko Teamsy’. można wdrożyć na szybko tenant M365, zostać przy domenie *.onmicrosoft.com i sobie z Teamsów korzystać od razu. ale nie ma mowy o integracji, nie ma mowy o tym, żeby to post factum łączyć ze środowiskiem on-premise [technicznie się da, ale czas i koszty…], funkcjonalność będzie ograniczona, no i tak czy inaczej – trzeba to przecież zabezpieczyć… ma być zgodność z normami i bezpieczeństwo – a gdzie licencje EMS? a to będzie kosztowało …. w sumie to bez różnicy bo kwota już i tak przekroczyła jakiekolwiek wyobrażenia wstępne – coś co miało być szybkim wdrożeniem dla 5o osób okazuje się olbrzymim projektem – być może na długie miesiące. o kwotach nawet nie wspominam.

to tylko skrzynki Exchange

o bezpieczeństwie myślą niby wszyscy, niektórzy próbują, ale niewiele osób ma pojęcie co to w ogóle znaczy ‘bezpieczeństwo M365’. może inna anegdota, tym razem mniejsza firma, ale schemat [czy raczej końcowy efekt], który obserwuję bez względu na wielkość firmy:

“mamy pocztę w takim to serwisie, i kupiliśmy licencje o365 i będziemy migrować”

“a bezpieczeństwo? macie jakiś projekt/pomysł jak to zabezpieczyć?”

“ale to tylko skrzyneczki”

czy aby na pewno? najbardziej oczywistym elementem, który pewnie każdy wskaże – jest tożsamość. w rozwiązaniach Chmury publicznej bezpieczeństwo sqpia się głównie na tożsamości [i danych]. w nazwie ‘Chmura Publiczna’ dość kluczowe jest słowo ‘Publiczna’. każdy – skądkolwiek na świecie, może próbować się logować, atakować konta itd. ale to dopiero początek… o czym [z przerażeniem zauważam] się zapomina. przecież wystarczy pojedyncza licencja, choćby trial, choćby wygasła dawno temu – ale jeśli była, to uruchamiane zostały w ramach M365 usługi, które objęte są/były licencją! to że licencje wygasły – nie wyłącza usług w ramach tenanta – co najwyżej z usługi nie da się w pełni korzystać, ale ona działa. to, że firma chce ‘tylko skrzyneczki’, nie oznacza, że cała reszta nie istnieje. to nie jest onprem – w którym stawiamy sobie Exchange, a reszty nie ma, bo jeszcze nie zdecydowaliśmy czy instalować serwer SharePoint – te usługi są, działają, mają jakieś ustawienia wyjściowe, są dostępne – czyt. można próbować się do nich dostać. i nie mówię tylko o próbach włamania. zauważyłem, że powszechną praktyką jest przypisywanie użytkownikom pełnych licencji, bez wyłączania planów serwisowych – nawet jeśli firma jeszcze nie planowała z nich korzystać. a to oznacza, że użytkownicy mogą korzystać z pozostałych usług i zrobić sobie krzywdę. czy też firmie. np. przypadkiem udostępniając plik z danymi wrażliwymi, lub w ramach zabawy i nauki ustawić jakiś konektor, który automatycznie gdzieś tam wysyła maile czy kopiuje pliki…

a tych usług jest dużo: OneDrive, SharePoint, Teams, same grupy M365, co za tym idzie wieloraka możliwość współdzielenie plików na zewnątrz, możliwość dodawania dowolnych konektorów – i w Outlook i w Teams i w … można by tak wymieniać a szczegółów jest dużo.

a całe środowisko M365 projektowane jest przez DevOpsów tak, aby zaspakajać ich potrzeby. czyli wszycy-wszytko-wszytkim-zawsze-wszędzie-proszęBardzo. zupełnie jak na tych teaserach reklamowych Microsoft Teams – gdzie wszyscy są kreatywni, wszyscy piękni, młodzi i ambitni i świetnie adaptują te nowe super technologie. taaa… i rozgrzeszenie i życie wieczne za darmo, przy wyqpieniu Software Assurance.

życie zazwyczaj wygląda nieco odmiennie. dla tego…

ZABEZPIECZ SWOJE M365 KOMPLEKSOWO i AUDYTUJ

nie ma że ‘tylko skrzyneczki’ czy ‘tylko Teams’. trzeba wdrożyć minimum bezpieczeństwa dla *całego tenanta* – czyli wszystkich usług, bez względu no to czy dziś chcemy z nich korzystać. tym bardziej, że jest bardzo wiele elementów, związanych bezpośrednio z AAD i o365, które są dla wszystkich – a [prawie] nikt i tak tego nie konfiguruje zostawiając ustawienia wyjściowe, które są [za]bardzo liberalne. do tego trzeba pamiętać, że Chmura to nie jest ‘produkt w wersji X’ – to jest dynamicznie rozwijające się środowisko. dla tego nie wystarczy ‘zabezpieczyć’ – trzeba robić przeglądy, sprawdzać jakie nowe aplikacje się pojawiły, jakie dodatki – bo za chwilę pojawi się kolejna nowa aplikacja, która wymaga znów przyjrzenia się jej możliwościom i bezpieczeństwu, ocenić czy użytkownicy będą z niej korzystać i w jaki sposób i zaplanować co z nią zrobić i jak skonfigurować – bo wbrew dość powszechnej opinii – SaaS wcale nie oznacza, że tam się nic nie konfiguruje, czy że wszystko jest od razu bezpieczne.

jeśli myślisz poważnie o bezpieczeństwie a twoja firma musi być zgodna z normami – pomyśl od razu o licencjach EMS, M365sec, albo przynajmniej Business Premium dla mniejszych.

a po wiedzę – cóż, trzeba zgłosić się do odpowiednich konsultantów (:

eN.