JAVA Swift and Secure: Racing Towards Resilient Cybersecurity in Java Applications

0:09↗карам 13-та година като софтуерен

0:12↗инженер в компанията.

0:15↗А и другият интересен факт е, че имам

0:17↗близнаци, момче и момиче, но а

0:22↗стига толкова за мен. А последно само да

0:25↗ви кажа, на снимката съм върху един Opel

0:28↗Корса.

0:30↗който нито е бърз, нито е секюър. Но а

0:34↗затова днес ще ви представя

0:39↗как може да направим бърз и secкр

0:42↗продукт,

0:44↗като а

0:46↗съм ви подготвил в а

0:50↗всичките слайдове подред, а както може

0:54↗да видите в съдържанието, въведение аа

0:57↗основи на сигурността в Javaта.

0:59↗А, ще ви разкажа за високопроизводителни

1:03↗и бързи Java приложения. Подготвил съм и

1:07↗кратко или не толкова кратко демо

1:10↗а за това а как според мен е най-добре

1:16↗да бъде реализирано а такова приложение

1:20↗и а след това ще поговорим малко за

1:23↗демото. Ще ви разкажа аа в детайли

1:27↗всъщност а

1:29↗изобщо цялата структура, как може да

1:32↗бъде подобрено, разбира се, защото а без

1:35↗да се оправдавам, но нямах много време

1:37↗да направя страхотното демо, което исках

1:41↗и разбира се аа заключение е от всичко

1:45↗това като аа

1:49↗мисля, че видяхте на първия слайд QR

1:52↗кода, който може да сканирате. за Q&A аа

1:56↗сесията.

1:59↗Ам във въведението

2:03↗това е може би един несполучлив опит да

2:06↗ви илюстрирам бърза кола без спирачки и

2:11↗нали колко е всъщност Swift и не secюър.

2:16↗А та в общи линии

2:21↗това, което искам да да направя като

2:24↗въведение към вас по темата е, че

2:29↗винаги е най-добре да имаме баланс,

2:32↗нещата да са хем достатъчно бързи, хем

2:37↗достатъчно secкюър за а

2:41↗изобщо за това, което искаме да

2:43↗постигнем като краен резултат. А

2:47↗сега бях си подготвил една смешка да

2:50↗попитам публиката кое е по-важно да сме

2:54↗по-бързи или сигурни, но едва ли ще е

2:58↗толкова спочлива. По-скоро ще ви

3:00↗разкажа, че а предполагам повечето от

3:03↗вас знаят в продуктовия свят всички прод

3:08↗хора искат

3:10↗да имат от всичко по много. А аз лично

3:14↗си спомням за моя рецензент на

3:16↗дипломната работа. Просто реших да взема

3:20↗две бутилки. Едното американско, а

3:22↗другото руско и да му ги занеса, като да

3:27↗го попитам кое от двете иска, а той ми

3:30↗отговори, че иска и френско. Така че

3:33↗нали в в общи линии е същото и с а аа

3:38↗приложенията в

3:41↗IT света и в продадукт апликейшъните.

3:44↗Аа като

3:47↗реално освен бързо, освен сигурно искаме

3:50↗UA и UX да са на ниво. А, но това има

3:56↗своята цена, разбира се, като надявам се

3:59↗в делото да успея да ви покажа всъщност

4:03↗как може да не се лишим от всичките тези

4:06↗неща и да имаме един много добър

4:09↗продукт. Другото нещо, което исках да ви

4:12↗спомена във въведението и то отново

4:16↗засяга много secкюрити темата, е

4:21↗инцидента 2017 година с Еко ифакс. А

4:27↗предполагам хора от вас са се

4:29↗интересували и знаят много добре за

4:31↗него. А там

4:34↗изтехо около 150 милиона PI данни на

4:39↗американци. Като най-големият проблем

4:43↗всъщност

4:45↗беше, че аа около 200 000, ако не се

4:50↗лъжа, а бяха данните за PCI или по-скоро

4:55↗кредитни карти, а за хората, които не са

4:58↗в пеймт индустрията.

5:01↗А,

5:02↗беше от една доста малка уязвимост, бих

5:06↗казал, която просто те повече от четири

5:09↗месеца

5:11↗не бяха пачнали. И това, което нали

5:15↗исках да ви разкажа по тази тема, е

5:17↗по-скоро

5:19↗дори и малката а уязвимост може да

5:23↗събори целия продукт, както е в случая,

5:27↗нали, има освен финансови загуби, аа има

5:31↗и репутационни загуби за компанията. Та

5:36↗secюрити-то е много важно да се случва

5:40↗навреме

5:41↗и да не бъде подценявано.

5:44↗А тъй като

5:46↗нали това другото нещо, което исках да

5:48↗ви спомена е за Life Walk доста

5:51↗по-далечна година като а Security

5:55↗Bridge, но тогава тяхното CEO а Тот

6:00↗Дейвис решава

6:03↗да покаже, че въпреки пробива в тяхната

6:07↗система и откраднатите данни SSN и така

6:11↗нататък, всъщност Всъщност това не е

6:14↗абсолютно никакъв проблем. Като той на

6:18↗доста билборди и а автобуси беше а

6:24↗сложил своя SSN аа и трите си имена.

6:30↗Като в крайна сметка

6:34↗той беше сигурен, че няма какво да

6:36↗стане, щом хората знаят неговия сен и

6:38↗трите му имена. И нали той е CO на една

6:42↗от най-големите компании за PI данни в

6:46↗Щатите, но всъщност се оказа, че има а

6:50↗повече от 13 потвърдени кредита и над 80

6:55↗опита аа това да се случи. Така че

6:59↗никога не подценявайте

7:01↗а способността на другите и

7:04↗secкюрити-то.

7:07↗Сега в този слайд освен, че исках да се

7:12↗похваля, че наскоро бях в Хърватия и

7:15↗затова сложих замък, а всъщност

7:19↗то е основата на илюстрацията на

7:23↗secкюрити, така както аз я виждам. И

7:27↗реално външният роф е

7:31↗фаallла, а стената е аутентикацията.

7:36↗Стражата, който дебне отгоре е всъщност

7:40↗auorization и rй лимитите. А и вече е

7:44↗трудната зала

7:47↗със знамето. А всъщност това са

7:49↗криптираните данни.

7:52↗Като а

7:54↗това, което съм си подготвил като булет

7:56↗пойнти е всъщност какви са добрите

8:00↗практики в Java.

8:03↗и съм дал, извадил съм просто малък

8:06↗пример за това как може всъщност да

8:10↗използваме ранъм, който е бърз, но пък

8:13↗за сметка на това не е secure и е

8:15↗предвидим. А и всъщност good practice е

8:20↗да използваме secure random, който е

8:25↗малко по-бавен, но достатъчно бърз за а

8:30↗90% от нуждите, които бихме имали да го

8:33↗използваме

8:34↗и

8:36↗според мен е добра комбинация между а

8:40↗Swift and Secure. Аа, забравих да

8:43↗спомена, преди изобщо да измисля

8:46↗заглавието на презентацията, аа доста

8:49↗хора ме питаха за за Swift ли ще говоря.

8:52↗Не, аа няма да говоря за Swift като аа

8:56↗програмен код, а ще говоря само за Java.

8:59↗Swift в моите представи е аа бързина.

9:04↗Та

9:05↗връщайки се на темата по булет пойнтите,

9:08↗освен secure randъм, съм си подготвил

9:12↗най-добрите практики за това как да а

9:16↗използваме парола в нашите приложения,

9:21↗като а доста често сигурен съм много от

9:25↗вас са срещали а стринг за взимането на

9:29↗парола изобщо в обекта, но също Всъщност

9:34↗стринг е много опасен да бъде използван,

9:36↗тъй като реално а единственият начин, по

9:42↗който можеш да изчистиш паролата, когато

9:44↗е запаметена в стринг от JVM-а

9:49↗е а с чрез garbage колектора.

9:53↗Сега много от вас най най-вероятно ще

9:56↗кажатма ти можеш да извикаш garbage

9:59↗колектора с system.

10:02↗GC и той да дойде и да зачисти всъщност

10:07↗това, което е имало в стринга Passwърд.

10:10↗А аз по-скоро а бих обяснил така за

10:16↗хората, които не знаят, а system.g GC

10:20↗работи като по начина, по който да си

10:23↗извикаш сервитьор, нали? Вдигнал си

10:25↗ръка, а сервитьорът те е видял, но ще

10:30↗дойде, когато се освободи или когато се

10:32↗сети. А по същия начин е и с System GC.

10:37↗Така че за да можем бързо и лесно да се

10:39↗освободим и да изчистим паметта, а

10:43↗по-скоро е много по-добре да използваме

10:45↗масив очарове за парола.

10:49↗Като извадил съм и keyсто Java X

10:54↗криптографията.

10:56↗Това са добри практики, които всъщност

10:59↗без да използваме външни библиотеки а

11:02↗могат да ни помогнат директно вградени в

11:07↗Java а

11:09↗без това да използваме, както вече

11:12↗споменах, външна библиотека, защото

11:14↗рисковете за използване на външна

11:16↗библиотека са много големи.

11:19↗А, спомням си за един от секюрити

11:21↗бриджовете, които с моя колега Марто сме

11:25↗дискутирали. Беше една библиотечка за

11:29↗цветове в Anguюър. А

11:32↗бял хакер беше просто решил да дъмпи

11:36↗кредит карти чрез тази библиотечка.

11:39↗Мисля, че над 400 проекта го бяха

11:41↗интегрирали, защото са решили да

11:43↗използват нещо на готово.

11:46↗Та тук по-скоро препратката ми е

11:48↗използвайте а възможно най-близко до

11:51↗програмния език неща без външни

11:54↗библиотеки, без транзитивнита

11:57↗и така нататък. И в третата точка съм си

12:01↗извадил а всъщност всички Java Security

12:05↗Frameworks които

12:07↗а аз през годините съм се сблъсквал с

12:10↗тях. Направили са ми добро впечатление,

12:12↗а по-скоро са nтив и а реално могат да

12:17↗бъдат използвани

12:19↗в Java света за JVM, за контейнери.

12:24↗А като на първо място съм извадил

12:27↗всъщност Security Substма на Jossa,

12:31↗който от JBoss

12:34↗7 се промени, тоест след JBoss 7 от

12:38↗JBoss 8, а всъщност вече името му е El

12:41↗елитрон.

12:42↗А интересен факт за него е, че

12:47↗той е secюритийър

12:50↗на Jos и може да бъде конфигуриран и

12:56↗използван в

12:59↗голяма степен а като

13:04↗keyстоore, като auentкеationшъм базата,

13:07↗нали. Страхотно много възможности има.

13:12↗А, но за следващата точка Spring

13:16↗Security бях си подготвил отново една

13:19↗шега, която може да видите, а, че

13:21↗всъщност това е любимата библиотека на

13:23↗всички хора, занимаващи се сприн

13:27↗и secюрити, но

13:31↗най-големият проблем е, когато трябва да

13:33↗я конфигурираш. А исках да кажа, че тази

13:37↗шега се отнася както за Spring Security,

13:39↗така и за Electron, така и за Jaка

13:41↗Security, а за Java Enterprise

13:44↗подходите.

13:46↗Много е важно да се отделя време на

13:49↗всеки един такъв secюритифреймърк, да

13:51↗бъде естестван, да бъде аа със сигурност

13:56↗конфигуриран по начина, по който искаме

13:58↗да го използваме в нашия апликейшъ.

14:01↗и в същото време а това нещо да ни

14:05↗помогне за по-добро secюрити в фрейм в

14:11↗приложението, което използваме чрез Java

14:14↗фреймърка.

14:17↗А

14:19↗в следващия слайд това, което съм си

14:21↗подготвил, всъщност е

14:24↗а нещо, което а надявам се Дидо Цветанов

14:29↗е дошъл да да ме уважи днес и да гледа.

14:32↗А нещо, което разбрах от него. А

14:36↗всъщност чувал съм да го наричат

14:39↗функционално програмиране в Java, а нали

14:43↗по много различни начини, но става

14:46↗въпрос завъo

14:49↗и web Spring Flux апликейшъните

14:54↗аа където всъщност а ние получаваме

14:59↗както secкюрити, така и бързина

15:03↗и аа в същото време асинхронност на

15:09↗заявките.

15:10↗Аа неслучайно в картинката, която

15:14↗чатботъ ми генерира, затова може да

15:17↗видите блокинг и nonн блокинг

15:20↗рекуестите.

15:22↗А като а

15:25↗за блокинг рекуестите, предполагам

15:28↗всички от вас знаят, че реално на един

15:31↗тред имаме а една заявка и

15:38↗в някакви случаи, не даже не в някакви,

15:41↗в доста случаи това е страхотно, но е

15:44↗много важно да знаем, че то работи

15:46↗всъщност като да чакаш на гишето в

15:49↗пощата, нали? Ако човек пред теб попълва

15:52↗бавно формуляра, твоят ред ще дойде

15:56↗доста по късно и обратното, нали, ако е

15:59↗по-бърз, а ще можеш

16:03↗да стигнеш по-бързо до гисето.

16:05↗А докато чрез mono и а fкре reactти

16:12↗програминга

16:13↗а всъщност имаме nonнблокинг

16:16↗заявки които

16:20↗буквално

16:21↗ще видите в демото, че могат да летят

16:26↗в моите очи, дори и на моята машина,

16:30↗която не е чак толкова мощна.

16:35↗Моля, простете, само ще пийна малко вода

16:48↗в последната точка

16:50↗аа Java Performance съм си подготвил три

16:55↗булет пойнта,

16:57↗които а аз само съм тествал, но а те

17:03↗имат някои пререкзити като а специално

17:07↗за Virtuual Thread а трябва ви Java 21 и

17:13↗нагоре, а всъщност те заменят пула и

17:19↗това, което е много позитивно за тях е,

17:21↗че всъщност намаляват lancн tool.

17:24↗А като

17:27↗реално virual трейдовете,

17:30↗въпреки че се използва термина Virtuual,

17:33↗те не са виртуални като криптовалутите,

17:36↗нали? И аз съм фен на криптовалутите, да

17:38↗не ме разбирайте погрешно. А но

17:42↗доста често те работят по а много

17:46↗съвършен начин.

17:49↗А що се отнася до Гуви VM, а

17:54↗признавам си, много исках да подготвя

17:57↗демото с Грау VM, обаче а отново ще се

18:02↗оправдая, че нямах това време, което а

18:06↗исках да имам, така да го кажем. Но аа

18:09↗за GraVM това, което съм си подготвил и

18:12↗много искам да споделя с вас, е, че аа

18:15↗мно много често съм в програмните среди

18:19↗съм чувал колеги да казват ми тя Java е

18:24↗бавна, то JVM-ката докато я запалиш и

18:28↗така нататък и така нататък. Ами

18:30↗всъщност с GRVM нещата наистина наистина

18:34↗хвърчат. А та за следващата лекция към

18:38↗def.bg обещавам ще си подготвя демото с

18:42↗Grvm и ще го тестваме с в паралел със

18:47↗сприн и secюрити

18:51↗а частта.

18:53↗Като последното нещо, което искам да ви

18:55↗кажа е че

18:58↗реално

19:00↗всичко това, което споменахме и става

19:03↗въпрос за Open телеметри, нали, а

19:08↗много е хубаво да имаш secкюрити, много

19:10↗е хубаво да работи бързо твоя твоето

19:12↗приложение, но без подходящи телеметри и

19:16↗логинг всъщност

19:19↗ти си сляп И

19:22↗дори и да се опитат да те пробият, няма

19:25↗ня няма начин да разбереш, че това ще се

19:27↗случва.

19:30↗А сега ще ви покажа как работи един бърз

19:35↗аликейшъ

19:37↗а под натоварване

19:39↗като

19:41↗само една секунда

19:46↗да подготвя

19:51↗екрана.

20:06↗Да, надявам се вече виждате.

20:11↗Аа, подготвил съм си едно проектче,

20:13↗което след края на презентацията ще може

20:17↗всеки един от вас да си го свали. Ще го

20:19↗кача в GitHub, ще има линк в самата

20:22↗презентация за него.

20:25↗Сега набързо ще ви преведа и ще ви

20:28↗разкажа всъщност какво съм направил.

20:30↗Както виждате, не е а нещо голямо

20:33↗мащабно. А четири-пет клас един

20:37↗JavaScript, който използвам за тестове и

20:41↗а всичко това се случва с Mavon и

20:46↗един POM XML, в който съм конфигурирал

20:48↗Dependнanc. А използвам Bucket for J за

20:52↗Cash. А нещо, което съм си подготвил в

20:55↗следващия слайд след демото, да ви

20:58↗разкажа а защо всъщност какви са

21:02↗рисковете да използваме кеш, колко бързо

21:04↗е и така нататък.

21:07↗А това, което виждате като клас е rate

21:12↗limitтър, който всъщност имплементира

21:14↗уеб филтъра на спринфрейка.

21:17↗А, подготвил съм си реално

21:23↗max request per seconds конфигурация,

21:27↗която ако имах време естествено можех да

21:29↗я сложа в някакъв propъртиy tool,

21:33↗но а дори и с хардкода на мисля, че ще

21:36↗за за целите на демото а ще е добре. А

21:40↗като може да видите, а подготвил съм си

21:43↗един филтър аа чрез уеб филтърчейна аа

21:49↗на на база на който а предскочим ли този

21:54↗а

21:56↗тази константа, която споменах за Max

21:58↗request per seconds. Всъщност, а нашият

22:02↗сървър започва да връща Tomi Request 429

22:07↗като грешка. Подготвил съм си един бърз

22:11↗JWTл,

22:13↗а в който нещо, което не бих посъветвал

22:17↗никой, нали, за целите на нашето демо

22:19↗просто съм го направил. А expiration

22:22↗time на JWT-то ми е един час, както

22:24↗виждате. А Secret Kia отново е

22:28↗изхардкоден в Javaта. Това със сигурност

22:32↗е нещо, което а би трябвало да бъде

22:35↗заменено с

22:37↗Property във Volt или някакъв друг Key

22:41↗Secret Store, а откъдето да го

22:44↗извличаме. А пропуснах само да кажа защо

22:47↗expреation time за мен е аа

22:51↗пробив в системата. Реално, когато имаме

22:55↗толкова голям епиationшъ, всъщност ние

22:58↗оставяме много дълго отворена нашата

23:02↗система за хора, които може в кавички да

23:06↗не са аутентикирани,

23:08↗нали, и да се сдобият с JWT-то

23:12↗на даден usзър.

23:14↗Та в общи линии трябва да

23:17↗много да внимаваме с тайм мениджмънта на

23:20↗акюрити

23:23↗токъните, които издаваме и да са за

23:26↗точно определено време, за което ни

23:27↗трябва.

23:29↗Аа и последното нещо, което исках да ви

23:32↗покажа е трите пойнта, които съм си

23:36↗подготвил. Единият е за а генерирането

23:40↗на токъна. А другият е, който реално

23:45↗проверяваме secure датата и дали

23:48↗всъщност потребителят има

23:51↗валиден JWT токън, защото ще видите, ще

23:55↗се опитаме да го счупим с такъв

23:57↗невалиден

23:59↗и а един публичен, който а всъщност

24:05↗тук

24:07↗това е един от проблемите, за който

24:10↗споменах, когато ви показвах замъците аа

24:14↗от Хърватия. А, но реално secкюрити-то

24:19↗винаги е слоеве и уязвимостта в нашия

24:25↗апликейшън много често може да е точно

24:27↗такъв публичен end point, а тъй като той

24:32↗няма проверка, аа ако потребителят успее

24:36↗да пробие фалаа, реално и в този случай,

24:41↗нали, нямаме четене от базата, но може

24:44↗може да се стигне до SQL инжекшъни, до

24:47↗пренатоварване на базата, сриване на

24:50↗сървъра и така нататък. От тази гледна

24:53↗точка, това, което исках да ви спомена,

24:55↗много е важно публичните енпонти винаги

24:59↗да бъдат много добре дефинирани и да

25:04↗имат своя рейлимит филтър, а който а

25:11↗както ви казах, всъщност ние сме го

25:13↗ограничили в момента на максимум 10

25:17↗рекуеста в секунда,

25:20↗Като

25:22↗да преминем вече и към трошенето на

25:25↗апликейшъни. Ако има QA в залата,

25:28↗сигурен съм, че много ще се накефят.

25:31↗Ам преди доста години бях Q. Обожавах да

25:34↗троша неща. Явно и моите деца и те са

25:37↗QA, защото продължават да обожават да

25:39↗трошат някакви работи.

25:42↗А

25:44↗това, което съм си подготвил, е на K6

25:49↗един W scриpt, а който в себе си, както

25:53↗виждате, отново нещо много кратко, което

25:57↗със сигурност може да бъде екстенднато.

25:59↗А реално има virual usзъри в секунда,

26:05↗които ще натоварим системата. А

26:10↗реално дюрейшъна на атаката, но всичките

26:13↗тези неща аз съм ги направил да може да

26:15↗бъдат управлявани от конзолата.

26:19↗И единственото нещо, което трябва да

26:20↗направим, е да си генерираме един нов

26:23↗токън.

26:25↗Аа

26:27↗да, ей това е публичния ни endpint,

26:29↗както виждате. Това е публичен end point

26:32↗permission without token. А

26:37↗генерираме токънчето

26:40↗можем да го сложим в JWTio.

26:45↗А да видим всъщност е expiration,

26:47↗userма. Както виждате, а много а

26:52↗семплайън структура, нещо за което

26:55↗декември месец в отново в Java user

26:58↗групата говорих специално за JWT токъни

27:02↗и за Pass Keys. Аа много е важно в а

27:06↗JWT-то да не държим сензитив дета и

27:11↗отново да се опитаме да я минимиризираме

27:14↗до за само за а целите, за които ни

27:18↗трябва.

27:20↗Аа нашият токън а както виждате експарва

27:24↗в 2:30 след един час.

27:28↗Аа секунда.

27:31↗Така. Слагаме го.

27:40↗Така.

27:44↗Тук съм си подготвил 1200.

27:47↗Мислите ли дали ще издържи

27:51↗системата? Така. Това, което направих в

27:53↗момента, а ръннах нашия скрипт с 12

27:58↗рекуеста в секунда, 12 виртуални юзъра.

28:01↗А за 10 секунди е атаката,

28:05↗а или по-скоро, за да видим дали нашият

28:08↗апликейшън ще се държи както трябва. Ам

28:14↗това, което може да видите,

28:16↗абстрахирайте се откл че 75%. Това е

28:20↗чисто заради скрипта. Както виждате, тук

28:23↗са четири чека и на базата на това а

28:27↗всъщност ги дава, че те са фейлнали.

28:29↗Само 25% са минали. Тоест ние успяхме да

28:33↗направим 120 рекуеста като аа за 10

28:37↗секунди като макс request per second,

28:42↗както видяхте в моята конфигурация е 10.

28:46↗И а всъщност аз пуснах скрипта да върви

28:50↗с 12 рекуеста в секунда, което а може да

28:54↗видите тук, че се получава 83%,

29:00↗тоест 100 от рекуестите са успяли да аа

29:05↗получат статус 200, а другите са се а

29:10↗точно на на нашия рейд лимит и са 16% 20

29:14↗рекуеста всъщност не са успели да минат.

29:19↗Сега ам

29:21↗както виждате,

29:24↗аз си бях подготвил

29:26↗поне от моята гледна точка

29:28↗малък рейлимит.

29:31↗А как мислите дали със 100

29:35↗ма request per seconds ще се прави моята

29:39↗скромна машина?

29:42↗Сега ще го видим.

29:47↗Реално в момента процессваме.

29:50↗Аа

29:52↗секунда, че не съм го вдигнал.

30:01↗Реално в момента процессваме 100

30:03↗виртуално юзъра в секунда

30:06↗с това апликейшънче, за което ви

30:09↗споменах, че в следващите два слайда ще

30:12↗обясня в детайли изцяло а как се случват

30:17↗нещата в апликейшъна.

30:20↗А може да видите, успяхме да направим

30:22↗1000 рекуеста за 10 секунди. А,

30:25↗абсолютно всичките са ни върнали 200.

30:28↗Окей, тоест нашият сървър успява да

30:32↗процесне 100 куеста в секунда.

30:36↗Какво мислите дали ще успеем да

30:38↗процеснем 1000?

30:41↗Въпреки че, както ви казах, съм със

30:43↗скромна единица.

31:06↗Забравих да спомена, че ако искате да

31:08↗направите такъв тест с апликейшъна,

31:11↗който имам, просто трябва да си

31:13↗инсталирате графа на K6. А както

31:18↗видяхте, успяхме да процеснем 1000

31:22↗виртуални юзъра в секунда и дори и да се

31:26↗опитаме да атакуваме нашия сървър с 1500

31:33↗виртуални в секунда,

31:36↗той няма да започне да ни връща а

31:39↗internal server error 500, а той ще

31:42↗успее да процесне както може да видите

31:47↗абсолютно даже повече от 10 000 в случая

31:52↗рекуеста, които да му върнат 200

31:57↗и малко по-малко от 5000, които всъщност

32:01↗са блокирали тази атака. Така. А аз

32:06↗мисля, че няколко пъти се оправдах, че

32:08↗нямах време, но както виждате,

32:11↗най-големият минус в момента в моето

32:14↗демо е, че аз всъщност, ако гледам само

32:17↗сървър сайт, аз съм сляп. Аз в момента

32:21↗не знам какво се случва. Не знам, че

32:22↗някой ме бомби, не знам, че а се е

32:26↗случило изобщо, че поемам трафик 1000

32:30↗виртуални юзъра в секунда.

32:33↗Та това ми беше пойнът и за Open Telem.

32:38↗Много е важно винаги да имате добър

32:42↗логинг, добро secюрити

32:46↗и ако може апликейшъ да е бърз.

32:50↗А това беше с моето демоo.

32:54↗Само секунда.

32:58↗Така.

33:11↗Да, вече ви споменах всъщност а

33:14↗бързината без сигурност е катастрофа.

33:18↗нещо, което а всъщност е мейн поintта в

33:23↗моята презентация и

33:26↗реално UX-ъ също може да пострада от

33:30↗това, че сме решили да направим нашето

33:32↗приложение бързо.

33:35↗А що се отнася до демото, това, което

33:39↗съм си подготвил е всъщност, нали на

33:43↗първо място бързината не означава, че

33:47↗няма да имаме сигурност в нашия

33:50↗апликейшън. А другото нещо, което нали

33:54↗за за мен е супер важно, е винаги да

33:57↗имаме security filter chain, както в

34:00↗случая на нашия апликейшъ. А всъщност,

34:04↗когато решим, го пускаме този филтър,

34:07↗когато решим го спираме за тестови цели

34:10↗и за тестови енвармънти може това нещо

34:12↗да бъде спряно. А всъщност това, което

34:18↗видяхме в демото, е и че ние успяхме да

34:21↗направим reactти autuentication, а която

34:26↗както видяхте всъщност може да процесне

34:30↗над 1000 юзъра, които се аутентикират

34:33↗или удрят наш а наш end pointт, който аа

34:39↗изисква JWT или аутентикация

34:43↗и Аа най-важното нещо всъщност е, че

34:47↗нямахме никакви проблеми с а inputт

34:51↗output стрийма и че валидирането на

34:54↗токъна се случва супер бързо а с кеш,

34:59↗който е в меemoryто аа кеш, който както

35:04↗виждате съм оставил буlletт point в

35:07↗случая, че всъщност това, че кешираме

35:10↗нещо, не означава, че е несигурно.

35:13↗Напротив.

35:14↗А Bucket For, който в случая използвахме

35:18↗за това демо, всъщност а ни убеждава в

35:23↗обратното, а можем да използваме кеша,

35:27↗да е бърз, да е in memory и да работи.

35:33↗Да, съгласен съм, че в случая

35:36↗съм го пуснал на едно ядро, а реално на

35:39↗един нот работи. Ако искаме да имаме

35:43↗подобен аликейшън на повече от един

35:45↗Note, всъщност трябва да използваме

35:48↗споделен кеш, но отново Bucket For Jт

35:51↗такова решение,

35:53↗така че може в някои от последващите

35:57↗а ме а лекции да ви а запозная с това,

36:02↗но аа последното нещо, което аа не ви

36:07↗демонстрирах, е, че всъщност Аа много е

36:11↗важен,

36:13↗а много е важно да имаме

36:16↗тестинг, какъвто ви демонстрирах, защото

36:19↗реално това ни

36:22↗кара да се чувстваме сигурни, да не се

36:24↗паникьосваме, да знаем, че нашият

36:26↗апликейшън може да издържи на това

36:29↗напрежение и можем да го изтестваме

36:32↗много преди а prodъкшън фазата.

36:36↗Това, което съм си подготвил отново за а

36:41↗демото, което ви показах, една малка

36:43↗табличка всъщност какво успяхме да

36:46↗постигнем като скорост, сигурност и

36:50↗решение. В случая не блокираме потока,

36:54↗не правим скъпи inputт, outp

36:58↗и това го постигаме с монообте и JWT без

37:03↗база.

37:06↗За да имаме повече скорост в

37:08↗приложението, не е задължително да

37:10↗използваме сесия. Знам, че много често а

37:14↗prodctт хората искат да имаме сесия, за

37:18↗да могат да проследят потребителското

37:20↗поведение,

37:22↗но тя може да бъде добавена в фронт или

37:26↗на друго място, но не и в autнentication

37:30↗апотите, които използваме. И по този

37:32↗начин, както виждате, отново печелим

37:35↗скорост, сигурност, че нямамери

37:39↗лик чрез стейтовете и всъщност ние имаме

37:41↗state токъни. А

37:45↗третото нещо, което съм си извадил е, че

37:47↗успяхме на голямо натоварване нашия

37:50↗апликейшън.

37:52↗Не съм го тествал, признавам си, на 100

37:54↗000 рекуеста, но предполагам, че около

37:59↗10 000 дори и на моята скромна машина ще

38:02↗успее да издържи. А всъщност сигурността

38:06↗в това нещо е, че като имаме и рейлимит,

38:09↗реално по IP лимитираме

38:13↗бот атаките

38:16↗и а когато имаш скорост, дори и да

38:20↗добавим а външна библиотека,

38:24↗реално тя няма много да забави аспонс

38:27↗тайма и по този начин а всъщност ще

38:32↗спечелим аа да имаме хубав мониторинг на

38:35↗апликейшъна и а да не пропуснем някакво

38:39↗скрито поведение в бекнда.

38:44↗Ам

38:46↗последният слайд, който съм си подготвил

38:49↗е всъщност нещо, което мисля, че трябва

38:54↗да извадим като заключение от а тази

38:57↗лекция. Всъщност сигурността трябва да е

39:02↗by defлт.

39:03↗А да не е нещо, което

39:07↗го правим като фичър, да не е нещо,

39:10↗което в последствие мислим за него. А от

39:14↗моята гледна точка и предполагам на

39:17↗доста от вас, а всъщност ние трябва да

39:20↗започнем

39:21↗с секюрити-то в самото начало, самото

39:24↗начало на продукта, да го изговорим с UI

39:29↗и UX хората, да им разкажем всъщност

39:32↗какво трябва да направим, за да имаме

39:34↗бърз акюрити,

39:37↗да митва абсолютно всички аа

39:41↗очаквания за дадени от стейкхолдъри като

39:45↗регулации и така нататък, да има а 2

39:49↗autentication, биометрия и така нататък.

39:53↗и абсолютно винаги това нещо да бъде

39:57↗перформамс тествано, за да се знае

40:01↗всъщност какъв е лимитът на на нашия

40:05↗контейнер, на а приложението, което

40:09↗използваме, вдигаме, за да може винаги

40:12↗да си оставим някакъв буфер, ако сме

40:14↗успели, да речем, както е в нашия

40:17↗случай, да правим над 1500 рекуеста в

40:21↗секунда. Хубаво би било да го лимитираме

40:25↗не на 1500, за да сме на ръба, а поне с

40:28↗200 рекуеста по-надолу.

40:31↗А тъй като наскоро бях на една

40:35↗конференция

40:37↗Cyber Securюти конф в България, там бяха

40:42↗събрани доста

40:44↗полицейски комисари, хора от службите,

40:48↗занимаващи се с

40:50↗акюрити

40:52↗в IT света, но от държавните институции.

40:58↗Там две неща. Това са и последните ми

41:00↗два булет пойнта. Две неща ми направиха

41:03↗впечатление. Повечето от тях говореха

41:07↗за уязвимости аа през смартфона

41:12↗и всеки един от нас има. Ясно е, че това

41:16↗всъщност е новият autentтикейшън

41:19↗механизъм. Ние го използваме за

41:20↗абсолютно всичко, но трябва да знаем, че

41:25↗всъщност

41:27↗в момента там е там сме най-уязвими.

41:31↗И

41:33↗просто съвет от мен абсолютно всички

41:36↗мерки, които могат да бъдат взети за

41:38↗секюрити на вашия телефон, аа да го

41:42↗направите биометрика, face recognition и

41:45↗така нататък, тъй като нали нагледах се

41:49↗точно на тая конференция, която споменах

41:51↗на много случаи, в които

41:55↗а всъщност хората

41:59↗биват пробити през телефона, а и през

42:02↗това, че нали не са го защитили.

42:06↗Другото нещо, което

42:08↗много ми направи впечатление на на тая

42:10↗конференция, е, че се говореше само и

42:13↗единствено за пароли. Не само и

42:16↗единствено, но а голяма 90% от случаите

42:20↗бяха пароли или пинове.

42:23↗А нещо, което аз разбрах преди около две

42:27↗години, нещо, което реализирахме в

42:30↗Paysfe в нашата фирма, а това са така

42:34↗наречените Passки Keys.

42:37↗Ам, не знам колко от вас са запознати с

42:40↗тях, но наистина а за мен, особено след

42:44↗тази конференция,

42:46↗това е

42:48↗люшъ, към който трябва да се върви от

42:52↗гледна точка на това, че всъщност а те

42:56↗са непробиваеми

42:59↗по начина, по който е направено и

43:03↗разбира се много е важно и как ще бъде

43:06↗използвано в даденото приложение,

43:09↗но реално

43:12↗не могат да бъдат отгатнати, както

43:14↗паролата не могат да бъдат разбити, а и

43:17↗те те в повечето случаи се държат на а

43:22↗найр мястото на девайса, от който сте си

43:25↗го създали. Дали е телефон, дали е

43:28↗таблет, дали е лаптоп. Та това за точно

43:34↗за Паски говорех през декември.

43:37↗Разказах всъщност как ние сме го

43:40↗имплементирали, как сме го тествали. А,

43:44↗направихме абсолютно всичко необходимо

43:46↗за това нещо, като

43:50↗securюity тестинг,

43:52↗тестинг и така нататък и continuous

43:56↗integraation тестинг, който върви и към

43:58↗момента най-вероятно, ако отворя слака,

44:00↗ще мога да ви покажа последните

44:02↗резултати на апсентикеation

44:05↗тестинга.

44:06↗Та това е нещо, което според мен е

44:11↗бъдещето да вървим към акюрити без

44:15↗пароли, без те да могат да бъдат разбити

44:19↗от хакери

44:21↗и дали ще са пакис, дали ще са нещо

44:24↗друго. Мисля, че това е насоката.

44:28↗И

44:30↗последното нещо, което искам да ви кажа,

44:32↗е, че всъщност относно презентацията,

44:35↗разбира се, аа

44:38↗ако искаме да сме бързи, трябва да сме

44:41↗спокойни, трябва да сме помислили

44:43↗абсолютно всички сценарии

44:45↗и за да сме спокойни, трябва пък да сме

44:48↗сигурни.

44:52↗Имаме ли въпроси?

44:54↗>> Имаме няколко. Да. А така. Така че може

44:57↗да започнем с тях. Който още не си е

44:59↗задал въпросите, може да сканира Vivox-а

45:01↗и да пита Калоян. Ето тука почваме с

45:04↗този.

45:10↗А първият въпрос е защо Reactive

45:12↗Programing вместо Virtual Threads, вече

45:15↗не е ли риск да използваме външна

45:17↗библиотека, както е Reactтив? А

45:22↗в случая тя е интегрирана, но мисля, че

45:25↗го споменах на аа

45:29↗малко по-рано в презентацията. Споменах

45:32↗и за Virtuual Threads. Та за следващата

45:35↗презентация ще бъде подготвен с Virtual

45:37↗Threads и с Grow VM и да влезем в

45:40↗детайли, може да ги сравним и с Reactти

45:43↗програминга.

45:45↗По-добре ли е да ползваме Verк а вместо

45:48↗Webfкс откъм гледна точка на

45:50↗performance? А не съм запознат с Verк,

45:55↗признавам си. А, бих го погледнал,

45:59↗разбира се, да го сравня с уебкса и със

46:04↗сигурност

46:05↗нещо, което провокира интереса в мен.

46:09↗Благодаря за въпроса. Какво трябва да се

46:11↗съдържа във всяко сигурно Java

46:14↗приложение?

46:17↗Ами

46:19↗със сигурност

46:21↗на първо място йлими, нещо, което а

46:25↗пропуснах да ви кажа. Всъщност рейлимит

46:28↗може да бъде направен а и на firewall и

46:32↗на по-ниско ниво, но за мен source of

46:35↗truth винаги трябва да е в Java

46:37↗апликейшъна, защото по този начин дори

46:40↗да сменим а JVM-а, фреймърка, на който

46:45↗го рънваме и така нататък, всъщност това

46:48↗ще остане и реално ще може да го

46:52↗виждаме.

46:54↗Еми мисля, че отговорих на всичките.