Martin Bekkelund

I drøyt to måneder har jeg benyttet meg av webtjenesten LinkedIn. Kort fortalt er LinkedIn et ypperlig verktøy for å administrere både ditt faglige og sosiale kontaktnettverk.

LinkedIn beskriver seg selv slik:

LinkedIn is an online network of more than 5.2 million experienced professionals from around the world, representing 130 industries.

When you join, you create a profile that summarizes your professional accomplishments. Your profile helps you find and be found by former colleagues, clients, and partners. You can add more connections by inviting trusted contacts to join LinkedIn and connect to you.

Your network consists of your connections, your connections’ connections, and the people they know, linking you to thousands of qualified professionals.

Selv har jeg for øyeblikket ti kontakter. Via mine kontakter har jeg mer enn 300 kontakter, og via deres kontakter igjen over 13 400 kontakter.

Via nettverket får man informasjon om ledige stillinger, kan tilby stillinger, utveksling av kunnskap, kunder og andre forretningsmessige tjenester.

Om ønskelig kan du komme i kontakt med meg via min LinkedIn-profil.

Fra tid til annen får jeg spørsmål om hvordan søking i databaser fungerer, for eksempel i søkemotorer. La det være sagt med en gang: Dette er et svært omfattende fagområde, og jeg er slett ingen guru på området. Hos min arbeidsgiver har vi ansatte som er sertifiserte på området, og som kun driver med databaser, det være seg installasjon, oppsett, drift og ikke minst optimalisering. Jeg er ikke en av de, men vil allikevel besvare det mest banale i denne artikkelen.

Innholdet i en database

En database består av minst en tabell, som igjen består av minst en kolonne og en post. Et eksempel kan være et personregister, illustrert med en tabell vi kaller “personregister”, slik:

Indekser

Når man skal gjøre søk i denne tabellen, vil det ved første øyekast være naturlig å lete igjennom hver eneste post i tabellen, for så å sjekke hvilke poster som matcher søkekriteriet. Det sier seg selv at dette vil ta uholdbart lang tid dersom tabellen inneholder mange poster. Derfor oppretter vi det vi kaller en indeks. En indeks kan kort beskrives som en innholdsfortegnelse, og opprettes som en egen, frittstående tabell i databasen, slik:

Et søk i en tabell uten indeks kalles “Table Scan” fordi søket ikke utføres mot en indeks (altså i indeks-tabellen), men i stedet går igjennom hver eneste post i tabellen.

Det opereres også med såkalte unike indekser. En unik indeks kun vil forekomme i én post i tabellen. I eksemplet over vil “Personnr” typisk være en unik indeks, da personnummeret er unikt for hver person. Forskjellen er at databasen vil stoppe søket i en unik indeks, når søkestrengen treffes, mens den vil søke igjennom hele indeksen i en vanlig indeks. En indeks kobles til en kolonne i hver tabell, omtrent slik:

Det kan opprettes en eller flere indekser per tabell, men det er viktig at designeren og utvikleren ikke oppretter for mange og store indekser, da dette fort kan få motsatt effekt, og går ut over hastigheten. Eksempelvis kan det i tillegg til “Personnr” kan det for eksempel opprettes en indeks på “Fornavn”, slik:

Vi sitter da igjen med selve tabellen og to indekser, slik:

På denne måten kan man legge til en indeks for hver kolonne i tabellen. Bakdelen er at også indeksene må vedlikeholdes. Det vil si at hvis programvaren skal gjøre en endring i en post, for eksempel endre etternavnet til Kari Nordmann til Hansen når hun gifter seg, vil databasen måtte skrive til samtlige indekstabeller, og således gå kraftig ut over hastigheten.

Søk

Et søk sendes til databasen fra programvarelaget via forretningslaget. I databasen vil et søk bli utført som en SQL-spørring, for eksempel:

1. SELECT * FROM personregister;

Søket vil returnere hele tabellen, mens et begrenset søk, for eksempel på personnummer, kun vil returnere de utvalgte data.

Dette er som nevnt en ekstrem forenkling, men det er prinsippet som er poenget.

ITavisen presenterer en artikkel om hvordan langfingrede, amerikanske datanerder har fått tilgang til folks bankkontoer ved å skaffe seg tilgang til butikkens nettverk. I denne artikkelen presenterer jeg en tilnærmet måte å gjøre det samme på her i Norge.

Du trenger følgende:

• En bærbar PC med trådløst nettverk.
• Et program for å sniffe nettverkspakker og gjerne et program for grafisk visning av nettverkstopografi.
• Kompetanse til å lese informasjonen i nettverkspakkene.
• En butikk med bankterminaler koblet til nettverket. (Ikke de med oppringt forbindelse.)
• Sistnevnte butikk har et trådløst, åpent nettverk koblet til det samme nettverket.
• En bil og litt god tid.

Du gjør som følger:

1. Parker så nærme butikken og det trådløse nettverket som mulig.
2. Koble deg til det trådløse nettverket og kontroller at signalstyrken er så god at pakketapet blir minimert.
3. Start pakkesnifferen og sett deg godt til rette.

Jeg skulle gjerne gitt mer detaljert informasjon om hvilke IP-adresser du skal sniffe på (da mottaker-IP-adressen er fast), særegenheter du skal se etter i pakker, hvilken bankterminalprogramvare dette fungerer med etc., men jeg mistenker at dette ikke er spesielt populært, så jeg lar det være…

Årsaken til at dette lar seg gjennomføre er fordi bankterminaltransaksjoner ofte kjøres over ukrypterte nettverk. I tillegg overføres all kortinformasjon ukryptert mellom terminalen og BBS. Unntaket er PIN-koden. Det vil si at kredittkorttransaksjoner lett lar deg finne kundens kredittkortnummer.

Du syntes kanskje at dette høres flåsete og usannsynlig enkelt ut, noe jeg selvfølgelig vil være enig i. Derimot har jeg, sammen med en produsent for bankterminaler og tilhørende programvare, gjennomført dette eksperimentet med mitt eget kredittkort, og det er oppsiktsvekkende å kunne trekke sitt eget kredittkortnummer ut av en nettverkspakke. Eksperimentet ble riktignok gjennomført for fire år siden, men så vidt meg bekjent har det ikke skjedd revolusjonerende endringer.

Dette er selvfølgelig veldig forenklet. Det er ikke helt rett frem å gjøre som beskrevet, men teknisk sett er det ingen hindringer.