Uthibitishaji wa AWS Client VPN: ruhusa za IAM si njia ya kuingia

Kumpa mtumiaji ruhusa ya kuunda au kuelezea sehemu ya mwisho ya AWS Client VPN hakumruhusu kuunganisha nayo. Hizi ni aina mbili tofauti za utambulisho: IAM husimamia simu za AWS API, na sehemu ya mwisho inakubali tu mbinu za uthibitishaji wa mteja zilizowekwa juu yake. Kwa hivyo mtumiaji anaweza kuwa na haki pana za konsoli na bado asiwe na chochote ambacho mteja wa VPN anaweza kuwasilisha. Amua ni mbinu gani sehemu ya mwisho inaamini, kisha amua kama handaki kamili ni umbo sahihi kwa ufikiaji unaotoa.

Utambulisho wa API si utambulisho wa handaki

Mtu anaposema «jukumu la IAM limeambatishwa, kwa nini VPN bado inashindwa», jibu kwa kawaida ni kwamba hakuna hatua katika mtiririko wa muunganisho inayosoma jukumu hilo. Mteja huwasilisha cheti, jina la mtumiaji na nenosiri la AD, au dai la SAML. Sehemu ya mwisho huthibitisha moja ya hayo kisha hugawa anwani.

IAM bado ni muhimu, tu baadaye na mahali pengine: kuunda sehemu ya mwisho, kuunganisha subneti, kuchapisha njia na kuandika kanuni za uidhinishaji ni vitendo vya API. Weka ruhusa hizo zikiwa na mipaka kwa waendeshaji wanaozihitaji badala ya kumpa kila mtumiaji uwezo wa kuandika upya kanuni za ufikiaji za sehemu ya mwisho.

Chagua kutoka mbinu ambazo sehemu ya mwisho inaunga mkono

AWS Client VPN inakubali uthibitishaji wa pande mbili unaotegemea cheti, uthibitishaji wa Active Directory na uthibitishaji wa shirikishi unaotegemea SAML. Cheti cha seva kinahitajika bila kujali mbinu ya mteja unayochagua, na usanidi unaochanganya mbinu unahitaji zote mbili kufaulu, si moja.

Vyeti ni vya bei nafuu kuanzisha na ndivyo vinavyokosewa kwa urahisi katika kiwango kikubwa, kwa sababu kila mtumiaji anahitaji kitambulisho na kila kuondoka kunahitaji kufuta. Uthibitishaji wa saraka huhamishia mzunguko huo wa maisha kwenye mfumo uliopo. Shirikisho huhamishia kwa mtoa utambulisho na kuongeza hatua ya kivinjari kwa mteja.

Soma usanidi wa sehemu ya mwisho yenyewe kabla ya kutatua tatizo la mteja. Ikiwa uthibitishaji wa pande mbili umewezeshwa pamoja na mbinu inayotegemea mtumiaji, mteja mwenye cheti halali lakini asiye na akaunti ya saraka bado atashindwa, na kosa kwa kawaida huonekana kama tatizo la jumla la kupeana mikono.

Shirikisho si kukabidhi funguo za ufikiaji

Usanidi wa SAML hauingizi funguo za ufikiaji za IAM au tokeni ya jukumu lililodhaniwa kwenye handaki. Mtoa utambulisho huthibitisha mtu, hurudisha dai, na sehemu ya mwisho hukubali chini ya uaminifu ulioweka. Kikao kinachotokana ni kikao cha VPN, si kikao cha AWS API.

Tofauti hiyo huamua nani anaweza kugundua nini. Matatizo ya IdP huonekana kama kosa la kivinjari au la mteja kabla handaki yoyote kuwepo, wakati matatizo ya handaki huonekana baada ya dai lililofanikiwa. Uliza ni ipi kati ya hizo mbili unaangalia kabla ya kufungua konsoli yoyote.

Baada ya kuingia, njia na uidhinishaji bado huamua

Uthibitishaji huipa kikao anwani; hauipi kikao lengwa. Njia za sehemu ya mwisho humwambia mteja ni subneti zipi za kutuma, kanuni za uidhinishaji huamua ni watumiaji gani wanaweza kufikia zipi kati ya subneti hizo, na vikundi vya usalama pamoja na ruhusa za lengo yenyewe huamua mengine.

Ndiyo sababu mtumiaji aliyethibitishwa kwa mafanikio bado anaweza kushindwa kufikia hifadhidata. Angalia muunganisho wa jedwali la njia kwa subneti, kanuni ya uidhinishaji ya kikundi cha mtumiaji na kikundi cha usalama kwenye lengo kwa mpangilio huo, kwa sababu kila kimoja huzalisha aina tofauti ya kumalizika kwa muda.

Kwa hifadhidata moja ya kibinafsi, linganisha na upitishaji wa bandari

Ikiwa kazi halisi ni muunganisho mmoja ulioidhinishwa kwa hifadhidata moja ya kibinafsi, handaki kamili ya mtandao ni chaguo na si sharti. AWS Systems Manager Session Manager inaweza kufungua kikao cha upitishaji wa bandari kwa nodi inayosimamiwa kupitia IAM, na nodi hiyo hufikia hifadhidata kwenye mtandao wa kibinafsi. Mtumiaji hupokea anwani ya VPC kamwe. Nodi inayosimamiwa huwa mwenyeji pekee anayeweza kufikia bandari ya hifadhidata, na kwa kawaida ndiyo iliyokuwa ikihitajika na ukaguzi wa usalama. Watumiaji kisha wanahitaji mteja wa ndani na amri ya kikao badala ya wasifu wa VPN.

Biashara ni wigo dhidi ya masharti ya awali. Upitishaji wa bandari unahitaji wakala wa SSM kwenye nodi inayosimamiwa, ufikivu wa mtandao kutoka nodi hiyo hadi hifadhidata, programu jalizi ya Session Manager kwenye mashine ya mtumiaji na ruhusa ya kuanzisha kikao hicho mahususi. Si njia ya kuingia kila subneti, na haitabeba itifaki zozote kama handaki inavyofanya.

Kwa vyovyote vile, weka utambulisho wa hifadhidata yenyewe mahali pake. Uthibitishaji wa TLS na uthibitishaji wa hifadhidata hazipotei kwa sababu njia iliidhinishwa na IAM, na kikao kilichoidhinishwa hakisemi chochote kuhusu ni majedwali gani mtumiaji anaweza kusoma.

Chagua kwa kuzingatia wigo na mzunguko wa maisha: handaki wakati watumiaji wengi wanahitaji maeneo mengi na unaweza kuendesha mzunguko wa maisha wa vyeti au saraka; kikao cha upitishaji wakati watu wachache wanahitaji huduma moja na unapendelea kutogawa anwani za mtandao. Kwa vyovyote vile, rekodi mbinu ya uthibitishaji, kanuni ya uidhinishaji na kuingia kwenye hifadhidata kama mambo matatu tofauti, kwa sababu hushindwa kwa tofauti.