Google frigav kildekoden til HIBA, en identitetsautorisationsmekanisme for SSH

Få dage siden Google afsløret gennem et blogindlæg nyheden om frigivelse af kildekoden for HIBA -projektet (Host Identity Based Authorization), der foreslår implementering af en yderligere autorisationsmekanisme til at organisere brugeradgang via SSH i forhold til værter (kontrollere, om adgang til en bestemt ressource er tilladt eller ej, når der godkendes ved hjælp af offentlige nøgler).

Integration med OpenSSH leveres ved at angive HIBA -driveren i direktivet AuthorizedPrincipalsCommand i / etc / ssh / sshd_config. Projektkoden er skrevet i C og distribueres under BSD -licensen.

Om HIBA

HIBA bruger standardgodkendelsesmekanismer baseret på OpenSSH -certifikater til fleksibel og centraliseret administration af brugerautorisation i forhold til værter, men kræver ikke periodiske ændringer af de autoriserede_nøgler og autoriserede_brugerfiler på siden af ​​de værter, som den er forbundet til.

I stedet for at gemme en liste med nøgler Gyldige offentlige og adgangsbetingelser i autoriserede filer (adgangskoder | brugere), HIBA integrerer værtsbindingsoplysningerne direkte i selve certifikaterne. Især er der blevet foreslået udvidelser til værtscertifikater og brugercertifikater, som gemmer værtsparametre og betingelser for at give brugeradgang.

Mens OpenSSH giver mange metoder, lige fra en simpel adgangskode til brug af certifikater, giver hver af dem udfordringer på egen hånd.

Lad os starte med at præcisere forskellen mellem godkendelse og autorisation. Den første er en måde at vise, at du er den enhed, som du hævder at være. Dette opnås normalt ved at angive den hemmelige adgangskode, der er knyttet til din konto, eller ved at underskrive en udfordring, der viser, at du har den private nøgle, der svarer til en offentlig nøgle. Godkendelse er en måde at afgøre, om en enhed har tilladelse til at få adgang til en ressource, normalt udført efter godkendelse sker.

Værts-verifikationen startes ved at ringe til hiba-chk-driveren angivet i direktivet AuthorizedPrincipalsCommand. Denne handler dekoder de udvidelser, der er indbygget i certifikaterne og baseret på dem, træffer beslutningen om at give eller blokere adgang. Adgangsreglerne er defineret centralt på certificeringsmyndighedens niveau (CA) og er integreret i certifikaterne på deres generationsstadium.

På certificeringscenterets side, der er en generel liste over tilladelser (værter, du kan oprette forbindelse til) og en liste over brugere, der kan bruge disse tilladelser. Hiba-gen-værktøjet er blevet foreslået at generere certifikater med indbygget tilladelsesinformation, og den funktionalitet, der kræves for at oprette en certifikatmyndighed, er blevet flyttet til hiba-ca.sh-scriptet.

Under brugerforbindelsen bekræftes de legitimationsoplysninger, der er angivet i certifikatet, af den digitale signatur fra certificeringsmyndigheden, som tillader, at alle verifikationer udføres fuldt ud på destinationsværtsiden hvortil forbindelsen foretages, uden at kontakte eksterne tjenester. Listen over CA -nøgler, der certificerer SSH -certifikater, er angivet af TrustedUserCAKeys -direktivet.

HIBA definerer to udvidelser til SSH -certifikater:
HIBA -identiteten, der er knyttet til værtscertifikaterne, viser de egenskaber, der definerer denne vært. De vil blive brugt som kriterier for at give adgang.
HIBA -tilskuddet, der er knyttet til brugercertifikater, viser de begrænsninger, som en vært skal opfylde for at få adgang.

Udover direkte linkning af brugere til værter, HIBA giver dig mulighed for at definere mere fleksible adgangsregler. For eksempel kan værter knyttes til oplysninger såsom placering og type service, og ved at definere brugeradgangsregler tillade forbindelser til alle værter med en bestemt type service eller til værter på et bestemt sted.

Endelig hvis du er interesseret i at vide mere om det om noten kan du kontrollere detaljerne I det følgende link.


Efterlad din kommentar

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *

*

*

  1. Ansvarlig for data: AB Internet Networks 2008 SL
  2. Formålet med dataene: Control SPAM, management af kommentarer.
  3. Legitimering: Dit samtykke
  4. Kommunikation af dataene: Dataene vil ikke blive kommunikeret til tredjemand, undtagen ved juridisk forpligtelse.
  5. Datalagring: Database hostet af Occentus Networks (EU)
  6. Rettigheder: Du kan til enhver tid begrænse, gendanne og slette dine oplysninger.