Dilysu AWS Client VPN: nid yw caniatâd IAM yn ddull mewngofnodi

Nid yw rhoi caniatâd i ddefnyddiwr greu neu ddisgrifio pwynt terfyn AWS Client VPN yn gadael i’r defnyddiwr hwnnw gysylltu ag ef. Dau fath gwahanol o hunaniaeth yw’r rhain: mae IAM yn llywodraethu galwadau AWS API, ac mae’r pwynt terfyn yn derbyn yn unig y dulliau dilysu cleient sydd wedi’u ffurfweddu arno. Felly gall defnyddiwr fod â hawliau consol eang ac eto heb unrhyw beth y gall cleient VPN ei gyflwyno. Penderfynwch pa ddull mae’r pwynt terfyn yn ymddiried ynddo, yna penderfynwch a yw twnnel llawn yw’r siâp cywir ar gyfer y mynediad rydych chi’n ei roi.

Nid yw hunaniaeth API yn hunaniaeth twnnel

Pan fydd rhywun yn dweud «mae’r rôl IAM wedi’i chysylltu, felly pam mae’r VPN yn dal i fethu», yr ateb fel arfer yw nad oes unrhyw gam yn y llif cysylltu yn darllen y rôl honno. Mae’r cleient yn cyflwyno tystysgrif, enw defnyddiwr a chyfrinair AD, neu honiad SAML. Mae’r pwynt terfyn yn dilysu un o’r rhain ac yna’n neilltuo cyfeiriad.

Mae IAM yn dal yn bwysig, dim ond yn hwyrach ac mewn man arall: creu’r pwynt terfyn, cysylltu is-rwydweithiau, cyhoeddi llwybrau ac ysgrifennu rheolau awdurdodi yn gamau API. Cadwch y caniatâd hynny’n gyfyngedig i’r gweithredwyr sydd eu hangen, yn hytrach na rhoi’r gallu i bob defnyddiwr ailysgrifennu rheolau mynediad y pwynt terfyn.

Dewiswch o’r dulliau mae’r pwynt terfyn yn eu cefnogi

Mae AWS Client VPN yn derbyn dilysu cilyddol yn seiliedig ar dystysgrif, dilysu Active Directory, a dilysu ffederal yn seiliedig ar SAML. Mae angen tystysgrif gweinydd waeth pa ddull cleient a ddewiswch, ac mae ffurfwedd sy’n cyfuno dulliau yn gofyn i’r ddau lwyddo, nid un.

Tystysgrifau yw’r rhai rhataf i’w sefydlu a’r rhai hawsaf i’w cael yn anghywir ar raddfa, oherwydd bod angen cymhwyster ar bob defnyddiwr ac mae angen dad-ddilysu ar bob ymadawiad. Mae dilysu cyfeiriadur yn symud y cylch bywyd hwnnw i system bresennol. Mae ffederasiwn yn ei symud i ddarparwr hunaniaeth ac yn ychwanegu cam porwr at y cleient.

Darllenwch ffurfwedd y pwynt terfyn ei hun cyn dadfygio’r cleient. Os yw dilysu cilyddol wedi’i alluogi ochr yn ochr â dull sy’n seiliedig ar ddefnyddiwr, bydd cleient â thystysgrif ddilys ond heb gyfrif cyfeiriadur yn dal i fethu, ac mae’r gwall fel arfer yn edrych fel problem ysgwyd llaw gyffredinol.

Nid yw ffederasiwn yn trosglwyddo allweddi mynediad

Nid yw sefydliad SAML yn bwydo allweddi mynediad IAM na thocyn rôl tybiedig i’r twnnel. Mae’r darparwr hunaniaeth yn dilysu’r person, yn dychwelyd honiad, ac mae’r pwynt terfyn yn ei dderbyn o dan yr ymddiriedaeth a ffurfweddwyd gennych. Y sesiwn sy’n deillio yw sesiwn VPN, nid sesiwn AWS API.

Mae’r gwahaniaeth hwnnw’n penderfynu pwy all ddatrys beth. Mae problemau IdP yn ymddangos fel gwall porwr neu gleient cyn bod unrhyw dwnnel yn bodoli, tra bod problemau twnnel yn ymddangos ar ôl honiad llwyddiannus. Gofynnwch pa un o’r ddau rydych chi’n edrych arno cyn agor y naill gonsol neu’r llall.

Ar ôl mewngofnodi, mae llwybrau ac awdurdodi’n dal i benderfynu

Mae dilysu’n rhoi cyfeiriad i sesiwn; nid yw’n rhoi cyrchfan i’r sesiwn. Mae llwybrau’r pwynt terfyn yn dweud wrth y cleient pa is-rwydweithiau i anfon iddynt, mae rheolau awdurdodi’n penderfynu pa ddefnyddwyr all gyrraedd pa rai o’r is-rwydweithiau hynny, ac mae grwpiau diogelwch a chaniatâd y targed ei hun yn penderfynu’r gweddill.

Dyma pam y gall defnyddiwr sy’n dilysu’n llwyddiannus fethu â chyrraedd cronfa ddata o hyd. Gwiriwch gysylltiad y tabl llwybrau ar gyfer yr is-rwydwaith, y rheol awdurdodi ar gyfer grŵp y defnyddiwr, a’r grŵp diogelwch ar y targed yn y drefn honno, oherwydd bod pob un yn cynhyrchu math gwahanol o derfyn amser.

Ar gyfer un gronfa ddata breifat, cymharwch ag anfon porth

Os mai’r gwir dasg yw un cysylltiad cymeradwy â chronfa ddata breifat, dewis yn hytrach na gofyniad yw twnnel rhwydwaith llawn. Gall AWS Systems Manager Session Manager agor sesiwn anfon porth i nod a reolir trwy IAM, ac mae’r nod hwnnw’n cyrraedd y gronfa ddata ar y rhwydwaith preifat. Nid yw’r defnyddiwr byth yn cael cyfeiriad VPC. Y nod a reolir sy’n dod yr unig westeiwr sy’n gallu cyrraedd porth y gronfa ddata, sef fel arfer yr hyn yr oedd yr adolygiad diogelwch yn gofyn amdano. Yna mae defnyddwyr angen cleient lleol a gorchymyn sesiwn yn hytrach na phroffil VPN.

Y fasnach yw cwmpas yn erbyn rhagofynion. Mae angen asiant SSM ar y nod a reolir, cyrraedd y rhwydwaith o’r nod hwnnw i’r gronfa ddata, ategyn Session Manager ar beiriant y defnyddiwr, a chaniatâd i gychwyn y sesiwn benodol honno ar gyfer anfon porth. Nid yw’n llwybr i bob is-rwydwaith, ac ni fydd yn cario protocolau mympwyol fel y mae twnnel yn ei wneud.

Cadwch hunaniaeth y gronfa ddata ei hun yn ei lle beth bynnag. Nid yw dilysu TLS a dilysu’r gronfa ddata yn diflannu am fod y llwybr wedi’i awdurdodi gan IAM, ac nid yw sesiwn gymeradwy yn dweud dim am ba dablau y caiff y defnyddiwr eu darllen.

Dewiswch ar sail cwmpas a chylch bywyd: twnnel pan fydd angen llawer o gyrchfannau ar lawer o ddefnyddwyr a gallwch redeg cylch bywyd tystysgrifau neu gyfeiriadur; sesiwn anfon pan fydd angen un gwasanaeth ar ychydig o bobl ac y byddai’n well gennych beidio â dosbarthu cyfeiriadau rhwydwaith. Beth bynnag, cofnodwch y dull dilysu, y rheol awdurdodi a mewngofnodi’r gronfa ddata fel tri ffaith ar wahân, oherwydd maen nhw’n methu ar wahân.