Sisu
- 1. Tegevus pesastatud rühmadega
- 2. Üleminek ACL-idelt RBAC-ile
- 3. Arvutite haldamine
- Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
- 4. Kasutajakonto blokeeringute käsitlemine
- 5. Lubade tõus ja lohk
Allikas: Tmcphotos / Dreamstime.com
Ära võtma:
Siit saate teada viis AD põhivaldkonda, mis võivad vajada kolmanda osapoole tarkvara sekkumist.
Teie ettevõtte jaoks võib-olla isegi kriitilisem kui teie kõige hinnatum rakendus või kõige kaitstud intellektuaalomand on teie Active Directory (AD) keskkond. Active Directory on teie võrgu, süsteemi, kasutajate ja rakenduste turvalisuse keskmes. See reguleerib kõigi teie arvuti taristu infrastruktuuris olevate objektide ja ressursside juurdepääsu kontrollimist ning selle haldamiseks vajalike inimressursside ja riistvara ressursside märkimisväärse hinnaga. Ja tänu kolmandate osapoolte tarkvaratootjatele saate AD-i hallatavate ressursside repertuaari lisada ka Linuxi, UNIXi ja Mac OS X-i süsteeme.AD haldamine enam kui paarikümne kasutaja ja grupi jaoks muutub väga valusaks. Ja Microsoftsi põhiliides ja -korraldus ei aita seda valu leevendada. Active Directory pole nõrk tööriist, kuid selle mõned aspektid jätavad administraatorid otsima kolmanda osapoole tööriistu. See artikkel uurib AD-de peamisi halduslikke puudusi.
1. Tegevus pesastatud rühmadega
Uskuge või mitte, pesastatud AD-rühmade loomise ja kasutamisega on tegelikult seotud parimad tavad. Neid parimaid tavasid peaksid siiski leevendama sisseehitatud AD-i piirangud, nii et administraatoritel ei lubataks pesastatud rühmi laiendada rohkem kui ühele tasemele. Lisaks takistaks piirang olemasoleva rühma kohta rohkem kui ühe pesastatud rühma ärahoidmiseks tulevaste majapidamis- ja haldusprobleemide tekkimist.
Mitme rühmataseme pesastamine ja rühmadesse mitme grupi lubamine tekitab keerulisi pärimisprobleeme, hoiab mööda turvalisusest ja rikub organisatoorsed meetmed, mille ennetamiseks grupi juhtimine kavandati. Perioodilised AD-auditid võimaldavad administraatoritel ja arhitektidel AD-organisatsiooni ümber hinnata ja korrigeerida pesastatud rühmade laialivalguvust.
Süsteemiadministraatoritel on aastaid olnud aju „Gruppide haldamine, mitte üksikisikute haldamine”, kuid grupihaldus viib paratamatult pesastatud rühmade ja halvasti hallatavate lubadeni. (Siit saate teada Softerra Adaxesi rollipõhise turvalisuse kohta.)
2. Üleminek ACL-idelt RBAC-ile
Kasutajakeskselt juurdepääsukontrolli loenditelt (ACL) AD-i juhtimisstiilist loobumine ettevõttepõhisemale rollipõhise juurdepääsu juhtimise meetodile (RBAC) näib olevat lihtne ülesanne. AD-ga mitte nii. ACL-ide haldamine on keeruline, kuid RBAC-ile üleminek pole ka pargis jalutamine. ACL-ide probleem on see, et AD-l pole lubade haldamiseks keskne asukoht, mis muudab halduse keerukaks ja kulukaks. RBAC üritab õigusi ja juurdepääsurikke leevendada, käsitledes juurdepääsuõigusi rolli, mitte üksikisiku kaupa, kuid see jääb endiselt tsentraliseeritud õiguste haldamise puudumise tõttu ebapiisavaks. Kuid sama valus kui RBAC-ile kolimine on palju parem kui lubade käsitsi haldamine kasutaja kohta ACL-ide abil.
ACL-id ei suuda skaleeritavust ja vildakat juhitavust, kuna nende ulatus on liiga lai. Rollid on alternatiivina täpsemad, kuna administraatorid annavad õigusi kasutajarollide alusel. Näiteks kui uudisteagentuuri uus kasutaja on toimetaja, siis on tal toimetaja roll AD-is määratletud. Administraator paigutab selle kasutaja redigeerijate rühma, mis annab talle kõik redaktorite nõutavad õigused ja juurdepääsu, ilma et kasutaja oleks samaväärse juurdepääsu saamiseks liidetud mitmesse teise rühma.
RBAC määratleb õigused ja piirangud rolli või tööfunktsiooni alusel, selle asemel et määrata kasutaja mitmesse rühma, millel võivad olla laiemad õigused. RBAC-i rollid on väga konkreetsed ega vaja paremate tulemuste, turvalisema keskkonna ja hõlpsamini hallatava turvaplatvormi saavutamiseks pesitsemist ega muid ACL-i keerukusi.
3. Arvutite haldamine
Uute arvutite haldamine, domeenist lahti ühendatud arvutite haldamine ja arvutikontodega midagi proovimist paneb administraatorid soovima minna lähimasse Martini baari - hommikusöögiks.
Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
Te ei saa oma programmeerimisoskusi parandada, kui keegi tarkvara kvaliteedist ei hooli.
Sellise dramaatilise väite põhjuseks on 11 sõna, mida te ei taha kunagi Windowsi administraatorina ekraanilt lugeda: „Selle tööjaama ja primaarse domeeni vaheline usalduslik suhe ebaõnnestus.“ Need sõnad tähendavad, et kavatsete veeta mitu katset ja võimalik, et mitu tundi, ühendades selle veidra tööjaama uuesti domeeniga. On kahetsusväärne, et tavaline Microsofti parandus ei tööta. Standardne parandus seisneb arvuti kontoobjekti lähtestamises Active Directory'is, tööjaama taaskäivitamises ja sõrmede ületamises. Muud taaskinnitamise abinõud on sageli sama tõhusad kui tavalised, põhjustades administraatoritel lahti ühendatud süsteemi uuesti pilti, et see uuesti domeeniga ühendada.
4. Kasutajakonto blokeeringute käsitlemine
Kontode blokeeringute iseteenindust ei saa parandada, ehkki mitu kolmanda osapoole tarkvaratootjat on selle probleemi lahendanud. Mõlemad kasutajad peavad enne uuesti proovimist ootama mõnda aega või võtma lukustatud konto lähtestamiseks ühendust administraatoriga. Lukustatud konto lähtestamine pole administraatorile murettekitav, ehkki see võib kasutaja jaoks pettumust valmistada.
Üks AD-i puudusi on see, et konto blokeeringud võivad pärineda muudest allikatest peale vale parooli sisestamise kasutaja, kuid AD ei anna administraatorile selle päritolu kohta vihjeid.
5. Lubade tõus ja lohk
Priviligeeritud kasutajatel on võimalus oma õigusi veelgi laiendada, lisades end teistesse rühmadesse. Priviligeeritud kasutajad on need, kellel on mõned kõrgendatud õigused, kuid kellel on lihtsalt piisavalt volitusi, et end täiendavatesse rühmadesse lisada, mis annab neile Active Directory'is täiendavad privileegid. See turvavea võimaldab sisemisel ründajal lisada järk-järgult õigusi, kuni domeeni üle on ulatuslik kontroll, sealhulgas võimalus lukustada teised administraatorid. (Likvideerige Active Directory identiteedihalduses ressursimahukad käsitsiprotseduurid. Siit saate teada.)
Lubade liikumine on seisund, mis tekib siis, kui administraatorid ei eemalda kasutajaid teatud privileegide grupist, kui kasutaja töö muutub või kui kasutaja lahkub ettevõttest. Lubade hiilimine võimaldab kasutajatel juurdepääsu ettevõtte varadele, mille jaoks kasutajal enam vajadust pole. Nii loa tõstmine kui ka loomemajandus tekitavad tõsiseid julgeolekuprobleeme. Nende tingimuste tuvastamiseks ja vältimiseks on olemas mitmesuguseid kolmanda osapoole rakendusi.
Alates väikestest ja lõpetades globaalsete ettevõtetega tegeleb Active Directory kasutajate autentimise, ressurssidele juurdepääsu ja arvutihaldusega. See on tänapäeval üks ettevõtluse kõige hinnatumaid võrgutaristu osi. Nii võimas tööriist kui Active Directory on, on sellel palju puudusi. Õnneks on Microsofti välised tarkvaratootjad laiendanud Active Directory funktsioone, lahendanud selle halvasti välja töötatud haldusliidese kujunduse, konsolideerinud selle funktsionaalsuse ja masseerinud mõned selle silmatorkavamad puudused.
Selle sisu tõi teile meie partner Adaxes.
