---

Hej,

Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en database.
Jeg går i overvejelser om at "kryptere" tallet - en float - men er i tvivl
om jeg bevæger mig ud på dybt vand. Mine tanker går på at behandle tallet
(fx. x*PI) men tallet skal jo kunne genskabes igen uden afrundinger. Jeg
kunne vælge at gemme det som varchar og lave en normal karakter-baseret
krypteringsalgoritme, men så kan jeg ikke regne på feltet på
database-niveau...

Forslag modtages med glæde.


--
Mvh
///M

---

"///M" <nospam@tdcadsl.dk> writes:

> Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en database.

Har databasen ikke adgangskontrol?
--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:
> "///M" <nospam@tdcadsl.dk> writes:
>
>> Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en
>> database.
>
> Har databasen ikke adgangskontrol?

Ikke for husets IT-Administrator, div. db-admins og sql-orme

PS. Glemte at skrive det er MS SQL 2000 jeg arbejder på.

--
Mvh
///M

---

"///M" <nospam@tdcadsl.dk> writes:

> >> Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en
> >> database.
> >
> > Har databasen ikke adgangskontrol?
>
> Ikke for husets IT-Administrator, div. db-admins og sql-orme
>
> PS. Glemte at skrive det er MS SQL 2000 jeg arbejder på.

Hvis DET er et problem, så vil jeg foreslå en ny database på en ny,
afskærmet maskine.

--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:
> "///M" <nospam@tdcadsl.dk> writes:
>
>>>> Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en
>>>> database.
>>>
>>> Har databasen ikke adgangskontrol?
>>
>> Ikke for husets IT-Administrator, div. db-admins og sql-orme
>>
>> PS. Glemte at skrive det er MS SQL 2000 jeg arbejder på.
>
> Hvis DET er et problem, så vil jeg foreslå en ny database på en ny,
> afskærmet maskine.

Jeg siger ikke det er et problem, blot noget som jeg måske gerne vil undgå.
Tænkt eksempel: En tyv stjæler vores backup-bånd og får dermed
kreditkort-numre på vores kreditkort...

Det er måske bare mig der ser en udfordring i at få diverse tal krypteret?
Jeg kan ikke forstå at det er okay at kryptere kodeord og tekst, men ikke
tal. :)

--
///M

---

"///M" wrote

> Jeg siger ikke det er et problem, blot noget som jeg måske gerne vil
> undgå. Tænkt eksempel: En tyv stjæler vores backup-bånd og får dermed
> kreditkort-numre på vores kreditkort...
>
Udgangspunktet var kontonummer, lønsum, data der skulle viderebearbejdes

> Det er måske bare mig der ser en udfordring i at få diverse tal krypteret?
> Jeg kan ikke forstå at det er okay at kryptere kodeord og tekst, men ikke
> tal. :)
>
Password, CPR eller Kortnummer er lidt anderledes
Tjek hvad datatilsynet stiller af krav når man gemmer ovenstående på varigt
medie

Tager man munden helt fuld så kan det også være relevant at kryptere
varebeholdning og/eller transaktionsdata

- Peter

---

"///M" <nomail@cibercity.dk> writes:

> Jeg siger ikke det er et problem, blot noget som jeg måske gerne vil undgå.
> Tænkt eksempel: En tyv stjæler vores backup-bånd og får dermed
> kreditkort-numre på vores kreditkort...

Kryptér backuppen.

Det er generelt en god ide hvis ens forretning afhænger af ens data,
og ikke så meget det der er i hovedet på folk.

> Det er måske bare mig der ser en udfordring i at få diverse tal krypteret?
> Jeg kan ikke forstå at det er okay at kryptere kodeord og tekst, men ikke
> tal. :)

Kodeord gemmes normalt krypteret fordi det eneste man vil gøre med det
er at sammenligne med et brugerangivet kodeord som også er krypteret.

Du vil gerne behandle dine data i databasen, og så skal de i hvertfald
på dét plan være ukrypterede.

I mine øjne vil det bedste stadig være en godt sikret databaseinstans
som kun du har adgang til.

--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:
> "///M" <nomail@cibercity.dk> writes:
>
>> Jeg siger ikke det er et problem, blot noget som jeg måske gerne vil
>> undgå. Tænkt eksempel: En tyv stjæler vores backup-bånd og får dermed
>> kreditkort-numre på vores kreditkort...
>
> Kryptér backuppen.
>
> Det er generelt en god ide hvis ens forretning afhænger af ens data,
> og ikke så meget det der er i hovedet på folk.
>
>> Det er måske bare mig der ser en udfordring i at få diverse tal
>> krypteret? Jeg kan ikke forstå at det er okay at kryptere kodeord og
>> tekst, men ikke tal. :)
>
> Kodeord gemmes normalt krypteret fordi det eneste man vil gøre med det
> er at sammenligne med et brugerangivet kodeord som også er krypteret.
>
> Du vil gerne behandle dine data i databasen, og så skal de i hvertfald
> på dét plan være ukrypterede.
>
> I mine øjne vil det bedste stadig være en godt sikret databaseinstans
> som kun du har adgang til.

Tak for alle jeres input.
Jeg tror ovenstående er argumentet jeg manglede for at droppe ideen :)


--
///M

---

///M wrote:

> Tak for alle jeres input.
> Jeg tror ovenstående er argumentet jeg manglede for at droppe ideen :)

Dog er der jo intet til hindring for at du fx "krypterer" userID nøglen
- altså referencen til den person dataene hører til - således at man
godt nok kan se tallene - men ikke umiddelbart kan henføre dem tilbage
til en given bruger/person i firmaet...

Dette vil i hvertfald ikke påvirke udregninger etc. - men spørgsmålet er
jo blot stadig... Hvis en administrator har adgang til følsomme data i
databasen - har han så ikke også adgang til at kunne se din kilekode og
dermed uanset hvad - kunne bryde din kryptering?

--
Med venlig hilsen
Geert Lund

---

Geert Lund wrote:
> Dette vil i hvertfald ikke påvirke udregninger etc. - men spørgsmålet
> er jo blot stadig... Hvis en administrator har adgang til følsomme
> data i databasen - har han så ikke også adgang til at kunne se din
> kilekode og dermed uanset hvad - kunne bryde din kryptering?

Jo, adgang, men dog ikke indsigt/forståelse. Selvfølgelig kan man så
argumentere at det kan han få eller købe sig til, men det er ikke der vi
skal ud. Ville bare ikke have haft at nysgerrige nemt kunne komme til data.

--
Mvh
///M

---

///M wrote:

> Jo, adgang, men dog ikke indsigt/forståelse. Selvfølgelig kan man så
> argumentere at det kan han få eller købe sig til, men det er ikke der vi
> skal ud. Ville bare ikke have haft at nysgerrige nemt kunne komme til data.

Fortsåeligt - jeg ville dog i det tilfælde vælge at lave det relationelt
således at man ikke uden SQL kendskab kunne udtrække sammenhængen mellem
personid og de følsomme data.

--
Med venlig hilsen
Geert Lund

---

Geert Lund wrote:
> ///M wrote:
>
>> Jo, adgang, men dog ikke indsigt/forståelse. Selvfølgelig kan man så
>> argumentere at det kan han få eller købe sig til, men det er ikke
>> der vi skal ud. Ville bare ikke have haft at nysgerrige nemt kunne
>> komme til data.
>
> Fortsåeligt - jeg ville dog i det tilfælde vælge at lave det
> relationelt således at man ikke uden SQL kendskab kunne udtrække
> sammenhængen mellem personid og de følsomme data.

God ide!

--
Mvh
///M

---

///M wrote:
> Geert Lund wrote:
>
>>///M wrote:
>>
>>
>>>Jo, adgang, men dog ikke indsigt/forståelse. Selvfølgelig kan man så
>>>argumentere at det kan han få eller købe sig til, men det er ikke
>>>der vi skal ud. Ville bare ikke have haft at nysgerrige nemt kunne
>>>komme til data.
>>
>>Fortsåeligt - jeg ville dog i det tilfælde vælge at lave det
>>relationelt således at man ikke uden SQL kendskab kunne udtrække
>>sammenhængen mellem personid og de følsomme data.
>
> God ide!

Nej. Nu kan jeg se at det er en MS SQL Server. Den undersøtter altså en
del sikekrhedsforandstaltninger, som bør gøre det muligt at forhindre
nysgerrige brugere i at se indholdet af de anførte felter.

Kryptering af nøgler og den slags løfter bare problemet til et helt nyt
niveau af uoverskuelighed. Det er en lappeløsning, som reelt ikke giver
nogen ekstra sikkerhed og samtidig påfører en masse nye problemer.

Mvh. Michael.

---

Michael Zedeler wrote:

> Nej. Nu kan jeg se at det er en MS SQL Server. Den undersøtter altså en
> del sikekrhedsforandstaltninger, som bør gøre det muligt at forhindre
> nysgerrige brugere i at se indholdet af de anførte felter.
>
> Kryptering af nøgler og den slags løfter bare problemet til et helt nyt
> niveau af uoverskuelighed. Det er en lappeløsning, som reelt ikke giver
> nogen ekstra sikkerhed og samtidig påfører en masse nye problemer.

Øh... nå... Jamen velkommen til - har du læst hele tråden?

--
//Geert

---

Geert Lund wrote:
> Michael Zedeler wrote:
> [klip]
>> Kryptering af nøgler og den slags løfter bare problemet til et helt
>> nyt niveau af uoverskuelighed. Det er en lappeløsning, som reelt ikke
>> giver nogen ekstra sikkerhed og samtidig påfører en masse nye problemer.
>
> Øh... nå... Jamen velkommen til - har du læst hele tråden?

Det tror jeg da. Er der noget specifikt, du mener jeg har overset?

Mvh. Michael.

---

///M wrote:
>
> Ikke for husets IT-Administrator, div. db-admins og sql-orme
> PS. Glemte at skrive det er MS SQL 2000 jeg arbejder på.
>
Hvis du ikke er tilfreds med sikkerhedsniveauet på MSSQL så var det
mere elegant og holdbart at udskifte dit rdbms

Btw hvis du har den fornødne adgang og ved hvor du skal kikke så er
de fleste ERP systemer fuldstændig åbne for alskens "hærværk" og
"luskeri"

- Peter

---

Peter Lykkegaard wrote:
> ///M wrote:
>>
>> Ikke for husets IT-Administrator, div. db-admins og sql-orme
>> PS. Glemte at skrive det er MS SQL 2000 jeg arbejder på.
>>
> Hvis du ikke er tilfreds med sikkerhedsniveauet på MSSQL så var det
> mere elegant og holdbart at udskifte dit rdbms

Det er jo ikke det der er problemstillingen - jeg er godt tilfreds med
sikkerheden - men jeg har alligevel krypteret mine intranet's brugeres
password som står i et andet felt. Jeg (firmaet) ønsker blot ikke at have
følsomme talværdier stående til ren aflæsning fordi man tilfælgdigvis har
db-admin rettigheder.

> Btw hvis du har den fornødne adgang og ved hvor du skal kikke så er
> de fleste ERP systemer fuldstændig åbne for alskens "hærværk" og
> "luskeri"

Ja sikkert - endnu en årsag til mit ikke skal være sådan. :)

--
Mvh
///M

---

"///M" wrote
>
> Det er jo ikke det der er problemstillingen - jeg er godt tilfreds med
> sikkerheden - men jeg har alligevel krypteret mine intranet's brugeres
> password som står i et andet felt.

Det er også normalt og her har man ikke brug for at lavev databehandling

> Jeg (firmaet) ønsker blot ikke at have følsomme talværdier stående til ren
> aflæsning fordi man tilfælgdigvis har db-admin rettigheder.

Hmm, ok
Hvor mange har adgang til sourcekoden der bruges i forb med din kryptering?

- Peter

---

///M wrote:
> Peter Lykkegaard wrote:
>
>>///M wrote:
>>
>>>Ikke for husets IT-Administrator, div. db-admins og sql-orme
>>>PS. Glemte at skrive det er MS SQL 2000 jeg arbejder på.
>>>


Du kan lave en stored procedure der arbejder på kryptered strenge, hvor
kryptering er 2vejs. Du kan bruge Delphi bl.a. til at lave stored
procedures til sql server.

Søg efter turbopower på sourceforge for at finde delphi komponenter til
kryptering. Der findes også delphi komponenter til at regisitrere stored
procedures i sql server.

--
Svend

---

"///M" <nospam@tdcadsl.dk> writes:

> Hej,
>
> Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en database.
> Jeg går i overvejelser om at "kryptere" tallet - en float - men er i tvivl
> om jeg bevæger mig ud på dybt vand. Mine tanker går på at behandle tallet
> (fx. x*PI) men tallet skal jo kunne genskabes igen uden afrundinger. Jeg
> kunne vælge at gemme det som varchar og lave en normal karakter-baseret
> krypteringsalgoritme, men så kan jeg ikke regne på feltet på
> database-niveau...

Jeg har ikke lige undersoegt det til bunds, men jeg har paa
fornemmelsen at dit krav om 'krypterede' vaerdier som man kan regne
paa, maa medfoere at krypteringen simpelt kan knaekkes bare man kender
et par af de rigtige loenvaerdier.

--
Kim Hansen

---

///M wrote:

> Jeg skal gemme nogle følsomme tal (løn-summer og kontonumre) i en database.

Hvis du skal bruge felterne til lønsummer, skal du ikke bruge floats.
Det er en almindelig fejl, som kan give nogle meget ubehagelige
problemer. Brug pengetyperne i stedet.

http://www.coker.com.au/~russell/ccode/types.html

> Jeg går i overvejelser om at "kryptere" tallet - en float - men er i tvivl
> om jeg bevæger mig ud på dybt vand. Mine tanker går på at behandle tallet
> (fx. x*PI) men tallet skal jo kunne genskabes igen uden afrundinger. Jeg
> kunne vælge at gemme det som varchar og lave en normal karakter-baseret
> krypteringsalgoritme, men så kan jeg ikke regne på feltet på
> database-niveau...

Lad være med det. Find en løsning, som databasen understøtter. Nogle
databaser har faktisk felt-niveau-privilegier, som du kan tildele. En
anden løsning, hvis de brugere, der ikke må se de hemmelige felter,
alligevel kun skal have læseadgang, er at oprette et virew, som du så
giver læseadgang til.

Hjemmelavede krypteringsalgoritmer og den slags vil med sikkerhed give
problemer.

Mvh. Michael.