На съвременния пазар, където индустриите използват различни софтуерни архитектури и приложения, е почти почти невъзможно да усетите, че вашите данни са напълно защитени. Така че, докато изграждате приложения, използвайки , проблемите със сигурността стават по-значими, тъй като отделните услуги комуникират помежду си и с клиента. И така, в тази статия за сигурността на микроуслугите ще обсъдя различните начини, които можете да приложите, за да защитите своите микроуслуги в следната последователност.
- Какво представляват микроуслугите?
- Проблеми, с които се сблъскват микроуслугите
- Най-добри практики за осигуряване на микроуслуги
Какво представляват микроуслугите?
Микроуслуги, известни още микросервизна архитектура , е архитектурен стил, който структурира приложението като колекция от малки автономни услуги, моделирани около бизнес домейн. И така, можете да разберете микроуслугите като малки индивидуални услуги, комуникиращи помежду си около единната бизнес логика. Ако искате да научите повече за задълбочените микроуслуги, тогава можете
Сега, често когато компаниите преминават от монолитна архитектура към микроуслуги, те виждат много предимства като мащабируемост, гъвкавост и кратки цикли на развитие. Но в същото време тази архитектура също въвежда няколко сложни проблема.
И така, следващата в тази статия за сигурността на микроуслугите, нека разберем проблемите, с които се сблъсква архитектурата на микроуслуги.
Проблеми, с които се сблъскват микроуслугите
Проблемите, пред които са изправени микрослужбите, са както следва:
Проблем 1:
Помислете за сценарий, при който потребителят трябва да влезе, за да получи достъп до ресурс. Сега, в архитектурата на микроуслугите, данните за вход на потребителя трябва да бъдат запазени по такъв начин, че потребителят да не се изисква за проверка всеки път, когато той / тя се опитва да получи достъп до ресурс. Сега това създава проблем, тъй като потребителските данни може да не са сигурни и също така могат да бъдат достъпни от тритеrdпарти.
Проблем 2:
Когато клиент изпрати заявка, тогава трябва да се проверят данните за клиента, както и да се проверят разрешенията, дадени на клиента. Така че, когато използвате микроуслуги, може да се случи така, че за всяка услуга да трябва да удостоверите и упълномощите клиента. Сега, за да направят това, разработчиците могат да използват един и същ код за всяка услуга. Но не мислите ли, че разчитането на конкретен код намалява гъвкавостта на микроуслугите? Е, определено има. И така, това е един от основните проблеми, с които често се сблъсква тази архитектура.
Проблем 3:
Следващият проблем, който е много очевиден, е сигурността на всяка отделна микрослужба. В тази архитектура всички микрослужби комуникират помежду си едновременно в допълнение към 3-теrdпартийни приложения. Така че, когато клиент влезе от 3rdстрана, трябва да се уверите, че клиентът няма достъп до данните на микроуслугите, така че той / тя да може да ги използва.
pmi-acp си заслужава
Добре, гореспоменатите проблеми не са единствените проблеми, открити в архитектурата на микросервиса. Бих казал, че може да се сблъскате с много други проблеми, свързани със сигурността въз основа на приложението и архитектурата, която имате. В тази бележка, нека продължим напред с тази статия за сигурността на микроуслугите и да знаем най-добрия начин за намаляване на предизвикателствата.
Най-добри практики за сигурност на микроуслугите
Най-добрите практики за подобряване на сигурността в микроуслугите са както следва:
Защита в механизъм за дълбочина
Тъй като е известно, че микроуслугите приемат всеки механизъм на гранулирано ниво, можете да приложите механизма Defense in Depth, за да направите услугите по-сигурни. От гледна точка на неспециалистите, механизмът „Защита в дълбочина“ е по същество техника, чрез която можете да приложите слоеве от мерки за сигурност, за да защитите чувствителните услуги. Така че, като разработчик, просто трябва да идентифицирате услугите с най-чувствителната информация и след това да приложите редица защитни слоеве, за да ги защитите. По този начин можете да се уверите, че всеки потенциален нападател не може да пробие сигурността с едно движение и трябва да продължи напред и да се опита да пробие защитния механизъм на всички слоеве.
урок за стъпка по стъпка в таблицата
Също така, тъй като в архитектурата на микросервиз можете да внедрите различни нива на сигурност на различни услуги, нападателят, който е успешен в експлоатацията на определена услуга, може да не успее да пробие защитния механизъм на другите услуги.
Токени и API шлюз
Често, когато отворите приложение, виждате диалогов прозорец с надпис „Приемете лицензионното споразумение и разрешение за бисквитки“. Какво означава това съобщение? Е, щом го приемете, вашите потребителски идентификационни данни ще бъдат съхранени и ще бъде създадена сесия. Сега, следващия път, когато отидете на същата страница, страницата ще бъде заредена от кеш паметта, а не от самите сървъри. Преди тази концепция да се появи в картината, сесиите се съхраняваха централно от страна на сървъра. Но това беше една от най-големите бариери в хоризонталното мащабиране, приложението.
Токени
И така, решението на този проблем е да се използват токени, за да се записват потребителските идентификационни данни. Тези символи се използват за лесно идентифициране на потребителя и се съхраняват под формата на бисквитки. Сега, всеки път, когато клиент поиска уеб страница, заявката се препраща към сървъра и след това сървърът определя дали потребителят има достъп до искания ресурс или не.
Сега основният проблем са жетоните, където се съхранява потребителската информация. Така че данните на жетоните трябва да бъдат криптирани, за да се избегне всяка експлоатация от 3rdпартийни ресурси. Jason Web Format или най-известният като JWT е отворен стандарт, който определя формата на маркера, предоставя библиотеки за различни езици и също криптира тези маркери.
API шлюзове
API шлюзовете се добавят като допълнителен елемент за защита на услугите чрез удостоверяване на маркера. The Шлюзът действа на входна точка за всички клиентски заявки и ефективно скрива микроуслугите от клиента. И така, клиентът няма пряк достъп до микроуслуги и по този начин нито един клиент не може да използва никоя от услугите.
Разпределено проследяване и управление на сесии
Разпределено проследяване
Докато използвате микроуслуги, трябва непрекъснато да наблюдавате всички тези услуги. Но когато трябва да наблюдавате едновременно огромно количество услуги, това се превръща в проблем. За да избегнете подобни предизвикателства, можете да използвате метод, известен като Разпределено проследяване. Разпределеното проследяване е метод за определяне на неизправностите и идентифициране на причината за това. Не само това, но можете също да идентифицирате мястото, на което се случва провал. Така че е много лесно да се проследи коя микрослужба е изправена пред проблем със сигурността.
Управление на сесията
Управлението на сесиите е важен параметър, който трябва да имате предвид, докато осигурявате микроуслуги. Сега сесия се създава всеки път, когато потребител влезе в приложение. Така че, можете да обработвате данните за сесията по следните начини:
- Можете да съхранявате данните за сесията на един потребител в определен сървър. Но този тип система напълно зависи от балансирането на натоварването между услугите и отговаря само на хоризонтално мащабиране.
- Пълните данни за сесията могат да се съхраняват в един екземпляр. Тогава данните могат да се синхронизират през мрежата. Единственият проблем е, че при този метод мрежовите ресурси се изчерпват.
- Можете да се уверите, че потребителските данни могат да бъдат получени от споделеното хранилище на сесията, за да се гарантира, че всички услуги могат да четат едни и същи данни за сесията. Но тъй като данните се извличат от споделено хранилище, трябва да се уверите, че имате някакъв механизъм за сигурност, за да получите достъп до данните по сигурен начин.
Първа сесия и взаимен SSL
Идеята на първата сесия е много проста. Потребителите трябва да влязат веднъж в приложението и след това да имат достъп до всички услуги в приложението. Но всеки потребител първоначално трябва да комуникира с услуга за удостоверяване. Е, това определено може да доведе до голям трафик между всички услуги и може да е тромаво за разработчиците да разберат грешки в такъв сценарий.
Достигайки до взаимен SSL, приложенията често са изправени пред трафик от потребители, 3rdпартии, а също и микроуслуги, комуникиращи помежду си. Но тъй като тези услуги са достъпни от 3rdпартии, винаги съществува риск от атаки. Сега решението на такива сценарии е взаимно SSL или взаимно удостоверяване между микросервизи. С това данните, прехвърлени между услугите, ще бъдат криптирани. Единственият проблем с този метод е, че когато броят на микроуслугите се увеличи, тъй като всяка услуга ще има свой собствен TLS сертификат, за разработчиците ще бъде много трудно да актуализират сертификатите.
3rdпартиен достъп до приложение
Всички ние имаме достъп до приложения, които са 3rdпартийни приложения. 3rdстраничните приложения използват API маркер, генериран от потребителя в приложението, за достъп до необходимите ресурси. Така че приложенията на трети страни могат да имат достъп до данните на конкретните потребители, а не до идентификационните данни на други потребители. Е, това беше по отношение на един потребител. Но какво, ако приложенията трябва да имат достъп до данни от множество потребители? Как мислите, че е удовлетворена такава молба?
Използване на OAuth
Решението е да се използва OAuth. Когато използвате OAuth, приложението подканва потребителя да упълномощи 3-теrdпартийни приложения, за да използват необходимата информация и да генерират токен за нея. Обикновено се използва код за оторизация, за да се поиска токенът, за да се гарантира, че URL адресът за обратно извикване на потребителя не е откраднат.
създаване на масив от обекти
И така, докато споменава маркера за достъп, клиентът комуникира със сървъра за упълномощаване и този сървър упълномощава клиента да предотврати други да подправят самоличността на клиента. Така че, когато използвате Microservices с OAuth, услугите действат като клиент в архитектурата OAuth, за да опростят проблемите със сигурността.
Е, хора, не бих казал, че това са единствените начини, чрез които можете да си осигурите услугите. Можете да защитите микроуслуги по много начини въз основа на архитектурата на приложението. Така че, ако сте някой, който се стреми да изгради приложение, базирано на микроуслуги, тогава не забравяйте, че сигурността на услугите е един важен фактор, за който трябва да внимавате. В тази бележка стигнахме до края на тази статия за сигурността на микроуслугите. Надявам се, че тази статия ви е била информативна.
Ако искате да научите Microservices и да създадете свои собствени приложения, разгледайте нашите което се предлага с обучение под ръководството на инструктори на живо и опит в реалния живот на проекти. Това обучение ще ви помогне да разберете задълбочено микроуслугите и ще ви помогне да постигнете майсторство по темата.
Имате въпрос към нас? Моля, споменете го в раздела за коментари на ” Микросервизна сигурност ”И ще се свържа с вас.