Google ga ut kildekoden for HIBA, en identitetsautorisasjonsmekanisme for SSH

Noen dager siden Google avduket gjennom et blogginnlegg nyheter om utgivelsen av kildekoden til HIBA -prosjektet (Host Identity Based Authorization), som foreslår implementering av en ekstra autorisasjonsmekanisme for å organisere brukertilgang gjennom SSH i forhold til verter (sjekke om tilgang til en bestemt ressurs er tillatt eller ikke når autentisering ved bruk av offentlige nøkler er ikke.

Integrasjon med OpenSSH er gitt ved å spesifisere HIBA -driveren i direktivet AuthorizedPrincipalsCommand i / etc / ssh / sshd_config. Prosjektkoden er skrevet i C og distribueres under BSD -lisensen.

Om HIBA

HIBA bruker standard autentiseringsmekanismer basert på OpenSSH -sertifikater for fleksibel og sentralisert styring av brukerautorisasjon i forhold til verter, men krever ikke periodiske endringer i de autoriserte tastene og autoriserte_brukerfilene på siden av vertene den er koblet til.

I stedet for å lagre en liste med nøkler Gyldige offentlige og tilgangsbetingelser i autoriserte filer (passord | brukere), HIBA integrerer vertsbindingsinformasjonen direkte i sertifikatene selv. Spesielt har det blitt foreslått utvidelser for vertssertifikater og brukersertifikater, som lagrer vertsparametere og betingelser for å gi brukeradgang.

Mens OpenSSH tilbyr mange metoder, fra et enkelt passord til bruk av sertifikater, byr hver av dem på utfordringer på egen hånd.

La oss starte med å klargjøre forskjellen mellom autentisering og autorisasjon. Den første er en måte å vise at du er enheten du påstår å være. Dette oppnås vanligvis ved å oppgi det hemmelige passordet som er knyttet til kontoen din, eller ved å signere en utfordring som viser at du har den private nøkkelen som tilsvarer en offentlig nøkkel. Autorisasjon er en måte å avgjøre om en enhet har tillatelse til å få tilgang til en ressurs eller ikke, vanligvis utført etter at autentisering skjer.

Bekreftelsen på vertssiden startes ved å ringe hiba-chk-driveren spesifisert i AuthorizedPrincipalsCommand -direktivet. Denne behandleren dekoder utvidelsene som er innebygd i sertifikatene og, basert på dem, tar beslutningen om å gi eller blokkere tilgang. Tilgangsreglene er definert sentralt på nivået til sertifiseringsmyndigheten (CA) og er integrert i sertifikatene på generasjonsstadiet.

På sertifiseringssenterets side, det er en generell liste over tillatelser tilgjengelig (verter du kan koble til) og en liste over brukere som kan bruke disse tillatelsene. Hiba-gen-verktøyet har blitt foreslått for å generere sertifikater med innebygd tillatelsesinformasjon, og funksjonaliteten som kreves for å opprette en sertifikatmyndighet er flyttet til hiba-ca.sh-skriptet.

Under brukerforbindelsen bekreftes legitimasjonen som er angitt i sertifikatet av den digitale signaturen til sertifikatmyndigheten, som lar alle verifikasjoner utføres helt på destinasjonsvertsiden som tilkoblingen er gjort til, uten å kontakte eksterne tjenester. Listen over offentlige CA -nøkler som sertifiserer SSH -sertifikater er spesifisert av TrustedUserCAKeys -direktivet.

HIBA definerer to utvidelser for SSH -sertifikater:
HIBA -identiteten, knyttet til vertssertifikatene, viser egenskapene som definerer denne verten. De vil bli brukt som kriterier for å gi tilgang.
HIBA -tilskuddet, knyttet til brukersertifikater, viser begrensningene som en vert må oppfylle for å få tilgang.

I tillegg til direkte kobling av brukere til verter, HIBA lar deg definere mer fleksible tilgangsregler. For eksempel kan verter knyttes til informasjon som plassering og type tjeneste, og ved å definere regler for brukertilgang, tillate tilkoblinger til alle verter med en bestemt type tjeneste eller til verter på et bestemt sted.

Endelig hvis du er interessert i å vite mer om det om notatet, kan du sjekke detaljene I den følgende lenken.


Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: AB Internet Networks 2008 SL
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.