Programmering

Java's sikkerhedsarkitektur

Denne måneds kolonne "Under hætte" er den første af en firedelt serie om Java's sikkerhedsmodel. De fire artikler vil fokusere på sikkerhedsinfrastrukturen indbygget i den virtuelle Java-maskine (JVM) og java.lang-biblioteket. Denne første artikel giver et overblik over sikkerhedsmodellen og beskriver JVM's sikkerhedsfunktioner.

Hvorfor sikkerhed?

Java's sikkerhedsmodel er et af sprogets vigtigste arkitektoniske træk, der gør det til en passende teknologi til netværksmiljøer. Sikkerhed er vigtig, fordi netværk giver en mulig angrebsvej til enhver computer, der er tilsluttet dem. Denne bekymring bliver især stærk i et miljø, hvor software downloades over hele netværket og udføres lokalt, som det f.eks. Gøres med Java-applets. Da klasse-filerne til en applet automatisk downloades, når en bruger går til den indeholdende webside i en browser, er det sandsynligt, at en bruger støder på applets fra ikke-betroede kilder. Uden nogen sikkerhed ville dette være en bekvem måde at sprede vira på. Således hjælper Java's sikkerhedsmekanismer med at gøre Java egnet til netværk, fordi de skaber en nødvendig tillid til sikkerheden ved netværksmobilkode.

Java's sikkerhedsmodel er fokuseret på at beskytte brugere mod fjendtlige programmer, der downloades fra ikke-betroede kilder på tværs af et netværk. For at nå dette mål leverer Java en "sandkasse", der kan tilpasses, hvor Java-programmer kører. Et Java-program må kun afspilles inde i sandkassen. Det kan gøre noget inden for sandkassens grænser, men det kan ikke foretage sig noget uden for disse grænser. Sandkassen til ikke-tillid til Java-applets forbyder f.eks. Mange aktiviteter, herunder:

  • Læsning eller skrivning til den lokale disk
  • Oprettelse af en netværksforbindelse til enhver vært undtagen den vært, hvorfra appleten kom
  • Oprettelse af en ny proces
  • Indlæser et nyt dynamisk bibliotek og kalder direkte til en indfødt metode

Ved at gøre det umuligt for downloadet kode at udføre bestemte handlinger beskytter Java's sikkerhedsmodel brugeren mod truslen om fjendtlig kode.

Sandkassen defineret

Traditionelt var du nødt til at stole på software, før du kørte det. Du opnåede sikkerhed ved kun at være forsigtig med at bruge software fra pålidelige kilder og ved regelmæssigt at scanne efter vira bare for at sikre, at tingene var sikre. Når en eller anden software fik adgang til dit system, havde den fuld tøjle. Hvis det var ondsindet, kunne det skade dit system meget, fordi der ikke var nogen begrænsninger på softwaren af ​​din computers runtime-miljø. Så i den traditionelle sikkerhedsplan forsøgte du at forhindre, at ondsindet kode nogensinde får adgang til din computer i første omgang.

Sandkassesikkerhedsmodellen gør det lettere at arbejde med software, der kommer fra kilder, som du ikke har fuld tillid til. I stedet for at sikkerhed etableres ved at kræve, at du forhindrer enhver kode, du ikke stoler på, nogensinde kommer ind på din computer, giver sandkassemodellen dig velkomstkode fra enhver kilde. Men da den kører, begrænser sandkassen koden fra utro, der ikke er tillid til, at tage handlinger, der muligvis kan skade dit system. Fordelen er, at du ikke behøver at finde ud af, hvilken kode du kan og ikke kan stole på, og at du ikke behøver at scanne efter vira. Sandkassen i sig selv forhindrer virus eller anden ondsindet kode, du måtte invitere til din computer, i at gøre nogen skade.

Sandkassen er gennemgribende

Hvis du har et ordentligt skeptisk sind, skal du være overbevist om, at en sandkasse ikke har lækager, før du stoler på, at den beskytter dig. For at sikre, at sandkassen ikke har lækager, involverer Java's sikkerhedsmodel alle aspekter af dets arkitektur. Hvis der var områder i Java's arkitektur, hvor sikkerheden var svag, kunne en ondsindet programmør (en "cracker") potentielt udnytte disse områder til at "gå rundt" i sandkassen. For at forstå sandkassen skal du derfor se på flere forskellige dele af Java's arkitektur og forstå, hvordan de fungerer sammen.

De grundlæggende komponenter, der er ansvarlige for Java's sandkasse, er:

  • Sikkerhedsfunktioner indbygget i den virtuelle Java-maskine (og sproget)
  • Klasselæsserarkitekturen
  • Klassefilverifikatoren
  • Sikkerhedsadministratoren og Java API
$config[zx-auto] not found$config[zx-overlay] not found