"Jesper Louis Andersen" <jlouis@miracle.mongers.org> skrev i en meddelelse
news:slrnbpj625.pan.jlouis@miracle.mongers.org...
> In article <slrnbpj2e2.k93.pope@mail.home.terminal.dk>,
> Povl H. Pedersen wrote:
>
> > Problemet der skal loses er at sikre en række offentlig tilgængeligt
> > webservere, ligesom der skal implementeres en losning så den interne
> > mail kan tilgås udefra, uden risiko for kompromitering af det interne
> > netværk.
>
> Det er det tekniske problem der skal loeses ja. Det interessante er
> derimod _hvorfor_ det problem skal loeses. Jeg forventer at jeres
> forrentning er afhaengige af den her raekke af offentlige webservere.
> Hvis ikke havde man nok ikke stillet dem op offentligt. Foer vi
> overhovedet taenker firewalls skal vi have bestemt det minimale
> featureset vi kan koere de servere med. Det hjaelper nemlig floejtende
> med en firewall hvis man har dynamik paa webserveren men kunne have
> klaret sig uden eksempeltvist og det saa viser sig at $SCRIPTING_LANG
> har et sikkerhedshul der er blevet udnyttet.
>
> Har i overvejet hvad konsekvenserne ved et eventuelt inbrud er og hvad
ricisi er
> for at der for eksempel kommer en tyv forbi og stjaeler maskinerne
> bagved.
Nu var det mig, som var fra firmaet. Ja, vi har tænkt på konsekvenserne af
et indbrud. Firmaet er inddelt i to sikkerhedszoner. Fordi at man har
nedbrudt 1. skal, har man ikke access til server-rummet. Det kræver en
sekundær nøgle eller en truck kørt til det niveau, hvor serverrummet er.
(Døren og væggene er speciel).
> Indtil videre daekker jeres minimale featureset:
>
> * Webserver, koblet til internet
> * Mail skal vaere tilgaengeligt paa LAN
>
> Hvad med for eksempel at kopiere alle mails til en diskette og
> flytte den fysisk og ikke have LAN paa nettet?
>
> Ja, det er provokorende ment. Men det loeser alle de problemer som
> i har lige nu. Det er muligt at det ikke er en acceptabel loesning,
> men saa maa i tilfoeje mere til det minimale featureset. Behoever i
> at NAT'e LAN? Kan en proxy goere det? Saa kunne man koere med
> proxyen og en mailserver som bastion hosts paa LAN. Hvis det er en
> Exchange-bastard skal man nok overveje qmail eller postfix paa en
> unix-maskine foran, saa exchange-serveren ikke eksponeres paa nettet.
>
> Saa jeres DMZ indeholder nu en proxy, en mailsver og en webserver. Intet
> af LAN ekponeres. Og ingen maskine i LAN har en default route.
> Med det setup er en firewall naeppe noedvendig. Det kan hoejest
> vaere interessant med normalisering af trafikken. Det kraever
> selvfoelgeligt at alle services der ikke skal anvendes er slaaet
> fra paa bastion hosts.
>
> Pointen er stadig den samme. Hvad har i egentlig brug for? Kan i klare
> jer med mindre og derved undgaa en masse problemer? Hvad er konse-
> kvensen ved et eventuelt indbrud? Hvad har i af backup hvis huset
> braender ned for et par anarkister synes at det skulle braende?
> Hvad er det helt praecist i forsoeger at beskytte? Hvis i ikke har
> identificeret det, hvordan ved i saa at jeres loesning yder den
> sikkerhed i forventer?
>
> Det er meget lettere at foretage fornuftige valg naar man har viden
> om det domaene man arbejder i. Hvis man har valgt teknisk loesning
> vil diskussionen kun handle om diskussionen af implementationen
> restrigeret under loesningen. Hvis man derimod foerer en diskussion
> om hvad det er man forsoeger at beskytte og mod hvem saa er
> man ikke begraenset af en bestemt loesning.
Problemet er at fortælle, hvad vi laver uden at kompromittere den løsning,
som allerede er i drift og hvor vi i en fortsat proces fra tid til anden
diskuterer, som sikkerheden kan forbedres inden for de meget begræsede
økonomiske rammer, som branchen dikterer.
Egentlig burde vi slet ikke udbyde web-services. Vi har ikke selv bygget
alle løsningerne og uanset hvor mange forbehold, man kan lave i en kontrakt
med et web-firma, så kan en kontrakt ikke garantere, at produktet ikke
rummer en script-fejl, som kan kompromittere data. Og ud fra devisen at alt
som man ikke selv har sikret, er usikker, så lever vi med en konstant
risiko.
Men vi havde ikke viden i huset til at bygge vores største web-service inden
for de tidsfrister, som ledelsen har udstukket. Derfor har vi investeret et
beløb i en web-løsning i en prisklasse, som har vækket forundring og
ærefrygt i branchen. Vi har bedt om et angreb-forsøg fra en af de firmaer,
som lever af at teste web-services og de har ikke fundet huller på denne
løsning. Men det er ikke nogen garanti.
Vores sikkerhedspolitik er i mange henseende drevet af, at vores forretning
simpelhen ikke ville kunne fortsætte uden vores hovedkvarter. Ja, vi har en
backupplan, hvor at vores data inden for 1-3 døgn vil kunne bringe til at
køre på en af vore andre lokationer. Den nødvendige hardware findes ikke på
det pågældende sted, så den anskaffes først. Vi udfører periodisk
tilbagelæsningskontrol på dubletter af vores backup-udstyr, men tilbage på
maskiner, som godt nok kan afvikle programmerne, men slet med den
brugerbelastningsgrad, som vi har på vores driftudstyr.
Funktionerne ville i hvert fald ikke kunne udføres af de mennesker, der
udfører det idag eftersom at den nærmeste lokation ligger i en anden
landsdel. Endvidere er meget af vores data baseret på dokumentation, som
vanskelig ville kunne genskabes uanset for nemt selve dataene ville kunne
genskabes.
Jeg kan som eksempel nævne at vores bilagsmateriale for et års fylder 30
reoler. Alene at ringe rundt til kunder/leverandører for at få kopier vil
tage flere måneder. Vi lever endvidere af at have trykprøver/film og alle
gamle sager har deres egen papirmappe.
Vi har overvejet at scanne denne dokumentation, men vi lever også af
farveægthed, så det ville kræve en speciel teknik.
Når jeg har valgt at poste det forslag, jeg har fået så hvar det fordi at
jeg fandte forslaget så banebrydende i forhold til den hemmelige opsætning,
vi har idag, at jeg måtte have et sekundær input i overvejelserne omkring
hvorvidt vi i det hele taget skal lave noget om.
--
Med venlig hilsen
Carsten Overgaard
http://www.carstenovergaard.dk/undskyld.htm