Како аутоматизовати оркестрацију права приступа у оквиру АВС С3 буцкета у 3 једноставна корака

Пре много година, када су локални Уник сервери са великим системима датотека били ствар, компаније су градиле опсежна правила за управљање фасциклама и стратегије за администрирање права приступа различитим фасциклама за различите људе.

Обично платформа организације служи различитим групама корисника са потпуно различитим интересима, ограничењима на нивоу поверљивости или дефиницијама садржаја. У случају глобалних организација, то би чак могло значити раздвајање садржаја на основу локације, дакле у основи, између корисника који припадају различитим земљама.

Даљи типични примери могу укључивати:

  • раздвајање података између развојног, тестног и производног окружења
  • продајни садржај није доступан широкој публици
  • законодавни садржај специфичан за земљу који се не може видети или приступити из другог региона
  • садржај у вези са пројектима где се „подаци о руководству” треба давати само ограниченој групи људи итд.

Постоји потенцијално бесконачна листа таквих примера. Поента је да увек постоји нека врста потребе за оркестрирањем права приступа датотекама и подацима између свих корисника којима платформа омогућава приступ.

У случају локалних решења, ово је био рутински задатак. Администратор система датотека је само поставио нека правила, користио алатку по избору, а затим су људи мапирани у корисничке групе, а корисничке групе су мапиране у листу фасцикли или тачака монтирања којима ће моћи да приступе. Успут, ниво приступа је дефинисан као приступ само за читање или приступ за читање и писање.

Сада гледајући АВС платформе у облаку, очигледно је очекивати да људи имају сличне захтеве за ограничења приступа садржају. Решење овог проблема сада мора бити другачије. Фајлови се више не опиру на Уник серверима већ у облаку (и потенцијално доступни не само целој организацији већ чак и целом свету), а садржај се не складишти у фасциклама већ у С3 буцкетс.

У наставку је описана алтернатива за приступ овом проблему. Изграђен је на искуству из стварног света које сам имао док сам дизајнирао таква решења за конкретан пројекат.

Једноставан, али веома ручни приступ

Један од начина како да решите овај проблем без икакве аутоматизације је релативно једноставан и једноставан:

  • Направите нови сегмент за сваку посебну групу људи.
  • Доделите права приступа групи тако да само ова одређена група може да приступи С3 групи.

Ово је свакако могуће ако се захтева веома једноставно и брзо решење. Међутим, постоје неке границе којих треба бити свестан.

Подразумевано, само до 100 С3 буцкета може да се креира под једним АВС налогом. Ово ограничење се може проширити на 1000 подношењем повећања ограничења услуге на АВС тикету. Ако та ограничења нису нешто због чега би се ваш конкретни случај имплементације забринуо, онда можете да дозволите сваком од корисника вашег различитог домена да ради на засебном С3 сегменту и да то кажете на дан.

  Постаните Семрусх придружени партнер и повећајте своју зараду

Проблеми могу настати ако постоје неке групе људи са вишефункционалним одговорностима или једноставно неки људи којима је потребан приступ садржају више домена у исто време. На пример:

  • Аналитичари података који процењују садржај података за неколико различитих области, региона итд.
  • Тим за тестирање је делио услуге које служе различитим развојним тимовима.
  • Пријављивање корисника који захтевају да направе анализу контролне табле на врху различитих земаља унутар истог региона.

Као што можете замислити, ова листа може поново да расте онолико колико можете да замислите, а потребе организација могу да генеришу све врсте случајева употребе.

Што ова листа буде сложенија, биће потребна сложенија оркестрација права приступа да би се свим тим различитим групама доделила различита права приступа различитим С3 сегментима у организацији. Биће потребни додатни алати, а можда ће чак и наменски ресурс (администратор) морати да одржава листе права приступа и да их ажурира кад год се захтева било каква промена (што ће бити врло често, посебно ако је организација велика).

Па како онда постићи исту ствар на организованији и аутоматизованији начин?

Ако приступ буцкет-пер-домаин не функционише, било које друго решење ће завршити са дељеним сегментима за више група корисника. У таквим случајевима потребно је изградити читаву логику додељивања права приступа у некој области која се лако мења или динамички ажурира.

Један од начина да се то постигне је коришћење ознака на С3 буцкетс. Ознаке се препоручује да се користе у сваком случају (ако ни за шта друго осим да би се омогућила лакша категоризација наплате). Међутим, ознака се може променити у било ком тренутку у будућности за било коју канту.

Ако је цела логика изграђена на основу ознака буцкет-а, а остатак иза је конфигурација која зависи од вредности ознака, динамичко својство је осигурано јер се може редефинисати намена буцкета само ажурирањем вредности ознака.

Које ознаке користити да ово функционише?

Ово зависи од вашег конкретног случаја употребе. На пример:

  • Може бити потребно одвојити канте по типу окружења. Дакле, у том случају, један од назива ознака ће бити нешто попут „ЕНВ“ и са могућим вредностима „ДЕВ“, „ТЕСТ“, „ПРОД“ итд.
  • Можда желите да раздвојите тим на основу земље. У том случају, друга ознака ће бити „ЦОУНТРИ“ и вредновати назив неке земље.
  • Или бисте могли да одвојите кориснике на основу функционалног одељења коме припадају, као што су пословни аналитичари, корисници складишта података, научници података, итд. Дакле, креирате ознаку са именом „УСЕР_ТИПЕ“ и одговарајућом вредношћу.
  • Друга опција би могла бити да желите да експлицитно дефинишете фиксну структуру фасцикли за одређене корисничке групе које су обавезне да користе (да не стварају сопствени неред фасцикли и да се тамо изгубе током времена). То можете поново да урадите са ознакама, где можете да наведете неколико радних директоријума као што су: „подаци/увоз“, „подаци/обрађени“, „подаци/грешка“ итд.
  Шта су Стаблецоинс? И како могу да пропадну

У идеалном случају, желите да дефинишете ознаке тако да могу да се логички комбинују и да формирају целу структуру фасцикли на сегменту.

На пример, можете да комбинујете следеће ознаке из примера изнад да бисте направили наменску структуру фасцикли за различите типове корисника из различитих земаља са унапред дефинисаним фасциклама за увоз за које се очекује да ће користити:

  • /<ЕНВ>/<УСЕР_ТИПЕ>/<ЦОУНТРИ>/<УПЛОАД>

Само променом вредности <ЕНВ>, можете редефинисати сврху ознаке (да ли ће бити додељена екосистему тестног окружења, дев, прод, итд.)

Ово ће омогућити коришћење исте корпе за много различитих корисника. Буцкетс не подржавају фасцикле експлицитно, али подржавају „ознаке“. Те ознаке на крају функционишу као потфасцикле јер корисници морају да прођу кроз низ ознака да би дошли до својих података (баш као што би урадили са подфолдерима).

Пошто смо дефинисали ознаке у неком употребљивом облику, следећи корак је да се направи С3 буцкет политика које би користиле ознаке.

Ако смернице користе називе ознака, ви креирате нешто што се зове „динамичке смернице“. То у основи значи да ће се ваша политика понашати другачије за сегменте са различитим вредностима ознака на које се смернице односе у форми или чуварима места.

Овај корак очигледно укључује неко прилагођено кодирање динамичких смерница, али можете да поједноставите овај корак користећи Амазон АВС алат за уређивање политика, који ће вас водити кроз процес.

У самој политици ћете желети да кодирате конкретна права приступа која ће се применити на сегмент и ниво приступа тих права (читање, писање). Логика ће прочитати ознаке на буцкет-у и изградити структуру фолдера на корпи (креирање ознака на основу ознака). На основу конкретних вредности ознака биће креиране потфасцикле, а дуж линије ће бити додељена потребна права приступа.

Лепа ствар код такве динамичке политике је што можете креирати само једну динамичку политику, а затим доделити исту динамичку политику многим сегментима. Ове смернице ће се понашати другачије за сегменте са различитим вредностима ознака, али ће увек бити у складу са вашим очекивањима за сегмент са таквим вредностима ознака.

То је заиста ефикасан начин управљања додељивањем права приступа на организован, централизован начин за велики број група, где се очекује да ће сваки сегмент пратити неке структуре шаблона које су унапред договорене и које ће ваши корисници користити унутар целу организацију.

Аутоматизујте пријем нових ентитета

Након дефинисања динамичких смерница и додељивања истих постојећим сегментима, корисници могу да почну да користе исте сегменте без ризика да корисници из различитих група неће приступити садржају (похрањеном у истом сегменту) који се налази у структури фасцикли у којој немају приступ.

Такође, за неке групе корисника са ширим приступом, биће лако доћи до података јер ће сви бити ускладиштени у истој канти.

Последњи корак је да се укључивање нових корисника, нових група, па чак и нових ознака учини што једноставнијим. Ово доводи до још једног прилагођеног кодирања, које, међутим, не мора да буде превише сложено, под претпоставком да ваш процес укључивања има нека врло јасна правила која се могу инкапсулирати једноставном, једноставном алгоритамском логиком (барем можете доказати на овај начин да ваш процес има неку логику и не ради се на превише хаотичан начин).

Ово може бити једноставно као креирање извршне скрипте помоћу АВС ЦЛИ команде са параметрима потребним за успешно уградњу новог ентитета на платформу. То чак може бити и низ ЦЛИ скрипти, извршних у неком одређеном редоследу, као што је, на пример:

  • цреате_нев_буцкет(<ЕНВ>,<ЕНВ_ВАЛУЕ>,<ЦОУНТРИ>,<ЦОУНТРИ_ВАЛУЕ>, ..)
  • цреате_нев_таг(<ид_буцкет_ид>,<таг_наме>,<таг_валуе>)
  • упдате_екистинг_таг(<ид_буцкет_ид>,<таг_наме>,<таг_валуе>)
  • цреате_усер_гроуп(<усер_типе>,<цоунтри>,<енв>)
  • итд.

Схватили сте поенту. 😃

Професионални савет 👨‍💻

Постоји један професионални савет ако желите, који се лако може применити на горе наведено.

Динамичке политике се могу искористити не само за додељивање права приступа локацијама фасцикли, већ и за аутоматско додељивање сервисних права за групе и корисничке групе!

Све што би било потребно је да се прошири листа ознака на буцкетс, а затим да се додају права приступа динамичким политикама за коришћење специфичних услуга за конкретне групе корисника.

На пример, можда постоји нека група корисника којима је такође потребан приступ одређеном серверу кластера базе података. Ово се несумњиво може постићи динамичким политикама које користе збирне задатке, посебно ако су приступи услугама вођени приступом заснованим на улогама. Само додајте коду динамичке политике део који ће обрадити ознаке у вези са спецификацијом кластера базе података и доделити привилегије приступа политици директно том одређеном ДБ кластеру и корисничкој групи.

На овај начин, укључивање нове корисничке групе биће извршно само овом јединственом динамичком политиком. Штавише, пошто је динамична, иста политика се може поново користити за укључивање многих различитих група корисника (очекује се да ће пратити исти шаблон, али не нужно исте услуге).

Такође можете да погледате ове АВС С3 команде за управљање сегментима и подацима.