Archives for backup

Securing your datacenter – Physical aspects

Securing your datacenter - Juha Jurvanen JufCorp AB

A basic guide to securing your datacenter- part 1

This blog post is intended only as a basic guide to securing your datacenter and it’s a repost with some new stuff added into it. I also wrote a couple of follow ups to it that I will repost later.

It is not intended to be the gospel of security since, well.. let’s be honest, there is no such thing as absolute security.

As an example, in Sweden there was a case where a computer was locked in a vault, with no network access whatsoever and only a few people had access to it and still, it leaked information to foreign countries. Yes . a computer controlled by the military.

Absolute computer security is a myth and a beautiful dream. With that said, system administrators can still do a lot to make more difficult to access data and prevent attacks and sabotage to their systems.
Let’s start off with physical aspects .

The actual georgraphic location

Where is your server actually located and who has physical access to it?

Resetting administrator passwords or root passwords

Once you gain physical access to a sever, there are numerous way of accessing the data. The root password or Active Directory Domain Administrator password or NDS Admin password can be easily reset (yes, the sentence “easily reset” is used loosely) with a USB stick and booting the server. Have look a at for instance HIren’s Boot CD, Burglar for NDS or just play around with Google and search for terms such as “Reset administrator password”, “decrypt password” and so on .
You’ll be amazed when you realize how easy it actually is. Personally, I always carry with me some USB stick that enables me to boot up any system and “have my way with it”
So, we need to secure the server from outside access. The data center must be protected with card keys, cameras and access control. We need to who and why they are in the data center in the first place.For instance, a janitor or cleaning staff tends to have complete access due to what they do. Many companies hire outside help to get these kinds of jobs done.

Sabotage and disrupted data services

If I wanted to gain access to server, I would try to infiltrate one of those subcontractors to get a job as a let’s say janitor, and try to gain access to the data center somehow and from there, I can basically do what ever I wanted with the servers.
Maybe my goal wouldn’t be to steal data but to kill the data operations by corrupting the filesystems on the servers (for instance just “piping” data into various files from command prompt or hding files behind other files ), randomly switch disks on RAID systems or just put small holes in network cables to cause network errors, trigger an EMP in the data center and so on .
There would be numerous ways to disrupt the data operations, once i gained access to the data center or servers room.

Information theft

If I’m out to steal data, I would probably not target the servers themselves but instead I’d start looking for backup tapes or backup disks. Far too many companies have their backups in the same location as the servers themselves and since the backups usually are not encrypted , I’d go for stealing a complete backup set, go home and start doing a scan of the tapes to figure out what backup software was used and then do a complete restore of it all.
The backups are most likely to contain the data I’m after, although probably a maximum of 24 hours old but from them I can gain access to all kinds of information about the operations and crack administrative passwords for the server systems and so on . In the comfort of my own data center. or my couch.
This way would of require some skill of Disaster Recovery scenarios and how to get data back from backups but I’m fairly sure I’m not he only one in the world who has the expertise in those matters.

Backups are always a weak point from several aspects.

You need to know who has access to them , at all times.
If you are company that for instance have your backups shipped to another location on a daily basis or weekly, you need to know that people handling them haven’t been compromised. It wouldn’t take that long for anyone with the proper skills do clone your tapes or disks en route to their destination and you would have no way of telling they’d been cloned. In that scenario, all of your critical data would be in the wild, without you actually knowing it.

If you are using any kind of online backup service, remember to choose your encryption password wisely and be extremely restrictive with who has the password. A lot of backup software do not let you change the encryption password without doing the first backup all over again, thus doubling your usage of space and your costs.
Still , I highly recommend you use an encryption password for several reasons.
If you don’t use it, it’s just pure laziness and fear of administrative hassle and that’s just not an excuse. The risk of people at your online backup provider being able to access your data is of course also an obvious risk. Do you know these people and how could you be absolutely certain that they aren’t poking around in your data and maybe giving it to your competitors?

If you are thinking about online backups there are a few very essential questions you should ask yourself but we’ll get back to that later in another post.
Do not use the same encryption password as you have for Root / Administrator / Admin . That´s just crazy talk. Use a password generator to create a unique password. This is also very much valid for tape backups or backups on NAS / disk. Always encrypt your backups with password and be very, very restrictive with who has the password.

If an employee quits your company or an outside consultant quits his project and he / she has had knowledge of the password, change it.

If you’re doing a planned Disaster Recovery test for instance, change the administrative passwords right after the DR test , thus not enabling anyone to reuse what they’ve found out during the test
During the actual DR test, you should be there and be the one that actually types in the encryption password for the backups, not any outside technicians or consultants , not even the online backup service provider or your Disaster Recovery Service Provider. You , and you alone should be the one that has those passwords.
I’ll will return to backup questions and stuff regarding DR plans and so further down the line in some upcoming blog post
So, the conclusion is, always know who and why people are in proximity of your servers and NEVER let anyone be there alone without supervision and here’s a few more pointers.

A short cheatsheet for datacenters

  1. Always have you data center locked and secured from unauthorized access, If you have the means, also have it secured against an EMP attack from the outside. Of course, I haven’t even touched the subjects but be sure your data center has all the necessary fire prevention/extinction equipment in place, UPS backups and , if possible, also an outside source for generating current in case the UPS or battery runs out of current. There should also be a system in place for protecting you servers against spikes in current.
    Be sure to know where water pipes are running in the building so you don’t place your server directly underneath one.
  2. Don’t keep cardboard or any other kind of flammable materials in the data center. Be sure to take them with you when you’ve set up a new server or switched disks. Don’t be lazy. The cost of laziness can be extreme.
  3. In the data center, always have your servers locked in cabinets that requires keys and access card to gain physical access to keyboards and stuff. Also remember to protect the cabling and the back of the servers! Never have a server logged on the console. Be sure to have all cabling to the and from the firewall and the internet access secured.
  4. If you’re “expecting company” i.e. external consultant and so on, be sure to think abut NOT having different kinds of network maps, administrative passwords and different kinds of information in plain sight for anyone to see. I’ve seen it hundreds of times, the IT department having their entire IT operations and information of their systems on white boards or on print on documents next to their workstations. It’s very quick and easy to take a picture of it with a cell phone and once you understand the infrastructure you can also start exploring weak points in it.
    Sure , it makes their lives easier but as one might gather, it also makes the life of the attacker easier. Knowledge is a powerful weapon, especially when it comes to data protection
  5. Don’t have software laying around in the data center with software keys and stuff on them . All it takes is a mobile phone for someone to coy your license keys thus possibly putting you in an awkard situation having to explain to Microsoft for instance how come that your Volume License keys are a bit too easy to find on Piratebay, thus putting you n the risk of your licenses becoming invalid and bringing your server operations to a halt , or at least a shoer disruption.
  6. Know where your backups are, at all times. Have them encrypted. If using online backup services, be sure to use an encryption key and , if possible, be sure to have restrictions on the online backup service providers end on to and from where backups and restores are allowed
  7. Do not allow mobile phones in the data center due to the risk of people photographing your equipment or software license keys or using the mobile phones to copy data via USB cables and stuff.
  8. If possible, disable any USB ports on your servers. This can be done in the BIOS (and of course also have a sysmtem password for accessing the BIOS, a unique one for each server ) or you can physically kill it by putting glue or semothing in there (I haven’t tried that myself so do try at your own risk .. )
  9. If you are sharing a data center with others, there is no need for you to have your company logo or anything revealing the servers are yours. Keep it as anonymous as possible. There is also no need for you to tell anyone where your servers are physically located (although it can be fairly easy for anyone to fin out using traceroute commands and so on ),
  10. Be sure to have a Disaster Recover Plan (DRP ) / Business Continuity Plan (BCP) if your site is compromised or an accident should occur. Also in this case, treat the secondary DR location as mission critical data. Far too often, the secondary site is forgotten and poorly updated.
  11. Once again, do not underestimate the powers of social engineering. Although it’s not hacking in the usual sense, it’s merely good acting but it can still be as harmful as I’m trying to point out here

So, there’s a few tips anyway and that’s just the start really. It’s not a complete recipe for securing your physical environment and I’m sure I’ve missed out loads of stuff but it’s a start anyways.

I hope you you liked this post and I’d love to hear you thoughts on it and if you want me to write a few others on the matters of securing your server operations, I was thinking in the lines of brute force protection, change management, 0day attacks, certificate management , password policies, protecting web servers and so on , You get the picture 🙂

// Juha Jurvanen

Contact me

Senior consultant in backup, IT security, server operations and cloud

Svenskt sjukhus förlorade data om 5000 patienter pga bristande backuper och övervakning 

backup återstartsplanering IT IT konsult IT säkerhet

De flesta företag och föreningar vet redan att backuper är viktiga att ha. I många avtal med externa leverantörer står det också att backuper ingår i deras tjänster.

Det som ofta inte står och inte heller görs är faktiska återstartstester och kvalitetskontroller på de backuper som tas.Särskilt inte av en oberoende tredje part. Det handlar såklart om att hålla kostnaderna nere.

Konsekvenserna dock av det kan ibland bli katastrofala pga detta. Vid ett haveri finns det flera aspekter att tänka på som t.ex hur man ska meddela sina kunder, vart ska backupen återläsas, hur och vilken ordning och hur lång tid får det egentligen ta? Hur stor dataförlust, om någon alls,  är acceptabel?

Dessa frågor och andra frågor kring  IT drift  är sånt jag hjälper företag och organisationer med.

Ett olyckligt exempel på hur man misslyckats med sin återstartsplaner och backupövervakning finns här i Computer Sweden nyligen. (exemplen är tyvärr väldigt många men majoriteten kommer aldrig fram i dagsljuset)

Ett sätt att i vart fall minimera risken är att anlita en tredje part som hjälper till att hålla ett öga på backuperna och även hjälper till att planera och genomföra återstartstester för övning och kvalitetskontroll.

Grundläggande säkerhet på Windows Server – uppdaterad

Grundläggande säkerhet på Windows server

backup disaster recovey kontinuitetsplaner IT säkerhet molntjänster syspeace

Jag skrev den här saken för ett tag sen men har lagt till lite nya länkar till programvaror o.s.v.

Kortfattat behlövs minst samtliga saker i den här listan för att uppnå i vart fall en grundläggande säkerhet på Windows server.
Tyvärr kommer servern ändå inte vara fullständigt skyddad även om du följer alla steg. Absolut säkerhet finns helt enkelt inte men det här är i vart fall en lista för att göra ett antal grundläggande inställningar och steg.

Installerade program

1. Se till att alla progranvaraor är uppdaterade med senaste säkerhetsuppdateringarna. Det här gäller operativsystemet, Exchange, SQL men även Adobe, Java och allt annat som finns installerat. Det här minskar risken för att råka ut för s.k. exploits som utnyttjkar sårbarheter i programvaror. Kika på t.ex. PDQeploy som jag tycker funkat bra i större miljöer för distribution.
Det skyddar dock inte mot en riktig Zero Day attack dvs när en sårbarhet blivit publikt känd men leverantören av programmet ännu inte släppt en uppdatering som avhjälper felet.

Antivirus

2. Se til att ha ett väl fungerande men inte för resusrkrävande antiviruws på samtliga system. Själv tycker jag om F Secures PSB lösning trots en del brister i software updater ämen den fungerar ändå väldigt väl för systemadministratör. Sätt upp larm på virusangrepp!

Katalog och filrättigheter

3. Se till att gå igenom alla katalog och filrättighter ordentligt och vilka användare och grupepr som har tillgång till vad. Tänk på att se till att användare , både interna och externa , endast ska kunna se det som de uttryckligen ska ha tillång till. Inget annat. Ett exempel är t.ex. att begränsa åtkomst till diskar och dölja diskar på Terminal Server (kolla t.ex. TS Hide Drives). Att sättw upp rättigheter på fil och katalognivå är oerhört kraftfullt sätt att begränsa tillgången till data. Testa innan du tillåter användare att nå servern. Det är alltid svårare att och jobbigare att fixa till saker i eftehand när servern är i drift. “Better to be denied than sorry”

Best practices

4. Se till att följa “best practices” för alla applikationer och tjänster du sätter upp. Googla. Ingen manual är komplett och programvarutillverkare tänker inte alltid på kringliggande saker som kan påverka säkerhet och kompabilitet.

Loggning

5. Se till att ha loggning påslaget där det går. Många program och funktioner har inte det påslaget som standard men du kan inte felsöka det du inte ser och att försöka hitat ett intrång eller annat fel i efterhand kan vara hopplöst om inte omöjligt.

Övervakning

6. Se till att ha en väl fungerande övervakning och inventering på hela ditt nät. Själv är jag en förespråkare för Spiceworks som är gratis som man kan göra väldigt mycket med.

SNMP och serveragenter

7. Om din server har olika typer av övervakningsagenter som kommer från tillverkaren (vilket de flesta har) se till att installera dem. De ger dig information om hur hårdvaran mår och larmar om olika typer av incidentter. Se till att också sätta upp larm från dem via mail till en funktionsbaserad maillåda dvs inte till en person. Se också till att ha en plan för incidenthantering på plats och utpekade ansvarig för olika typer av fel.

Group Policies

8. Group policies dvs grupp principer. Oerhört kraftfullt verktyg om du sätter dig in i det och kommer att underlätta administration, säkerhetshantering och användarhantering väldigt mycket.

SSL TLS och Internet

9. Om servern är nåbar från Intern, se till att ha giltiga SSL certifkat för alla tjänster so ska kommuniceras med. Det är inte så dyrt man kan tro och kommer underlätta också att få en del funktioner att fungera smärtfritt. Tänk dock på att bara installera ett SSL certifikat inte räcker, du måste också slå av en del svaga krypton o.s.v.

Onödiga tjänster och nätverksprotokoll

10. Stoppa tjänster, funktioner och nätverksprotokoll som inte används. Minimiera attackytan för hackers, både interna och externa, men spara även prestanda i serven. Du slipper också onödigt tjattrig nätverkstrafik på nätet . Behöver t.ex. DHCP Client vara igång på en server ? Samma princip gäller för skrivare och arbetsstattioner.

Lösenordspolicy

11 Tvinga komplexa lösenord för alla användare. Ett av de vanligaste sätten för hackers att ta sig in i system beror just på svaga lösenord som enkelt går att gissa sig till. Byt namn på administratören då kontot inte går att låsa i Windows. Här är det också viktigt att ha et fungerande intrångsskydd mot lösenordsattacker med Syspeace.

Namnstandard för inloggningar

12. Använd en bra namnstandard för inloggningar. Använd inte bara t.ex. förnamnn@ertföretag.se eller något annat som är för uppenbart och enkelt. Ju svårare det är för en hacker att gissa sig till ett användarnamn desto fler försök komemr behövas för att ta sig in i systemet. Även här är Syspeace en viktigt nyckel för hanteringen.

Backuper

13. Backuper, backuper och BACKUPER! Se till att ha fungerande backuper och rutiner för dem. Testa dem regelbundet , minst en gång om året. Att återläsa enskilda filer ur en backup är inte en återstartstest! Se även till att ha flera generationer av backuper och en IT policy som styr detta. Att bara ha en eller två generationer att kunna falla tillbaka på vid ett haveri kan vara katastrof t.ex. om backupen av någion anledning är korrupt och inte går att använda eller om ni blivit hackade och nmåste få tillbaka systemet till ett tillfälle ni vet med säkerhet är OK innan intrånget skedde.
Se till att ha MINST en fungerande enreation av backupern anågon annastans än i samma lokaler där servern är utifall det brinner eller blir inbrott.

Att ha disksystem som RAID och andra failolver-lösningar kmemr aldrig att ersätta backuper. All hårdvara kan falera, både fysiskt och logiskt som korrupta filsystem.
Ett tips här är också att slå på regelbundna VSS snapshots på alla diskar . Enkelt, stabilt och billigt sätt att ha flera generationer av data att tillgå –

Scanna , hacka , sök aktivt efter brister

14. Scanna din server med olika verktyg efter sårbarheter och tips för att öka säkerheten.

Brandväggar och kommunikationer

15. Tänk igenom hur serven kommunicerar med omvärlden vad gäller brandväggar och routing i nätet. Ha även den lokala brandväggen påslagen i Windows, trots att den står bakom en extern brandvägg.

Lösenordsattacker

16. Automatisk intrångshantering med Syspeace. I Windows går det inte att automatiskt hantera lösenordsattacker på ett vettigt sätt. De inbyggda mekanismerna kan t.o.m. göra mer skada än nytta. Att installera Syspeace löser mycket av problematiken direkt och är oerhört enkelt att installera och konfigurera.

Återstartsplaner för IT

17. Det här hör på sätt och vis ihop med punk 13 om backuper men se till att ha en vettig återstartsplan om något händer.

Microsoft Baseline Security Analyzer

18. Kolla med Microsoft Baseline Security Analyzer så du också följer deras rekommenadtioner. Den är inte heltäckande men användar för att ge en fingervisning

Kontakta mig för möte eller frågor

Tjänster jag kan hjälpa er med t.ex. IT säkerhet, backup restore, IT drift, projektledning, molntjänster och Syspeace

backup disaster recovey koninuitetsplaner IT säkerhet molntjänster syspeace

Jag tar även uppdrag som underkonsult till företag som vill inleda ett samarbete.

Den här sidan innehåller ett antal rubriker kring några av de saker jag kan hjälpa ert företag eller förening med.
Det är ett många saker och det är reultatet av 20 års erfarenhet som IT konsult.
Jag törs påstå att en stor del av min kompetens är just min breda erfarenhet och förståeälse för helheter i IT system och driftskritiska applikationer men även för affärprocesser och leda personal.

Backup restore, Disaster Recovery, kontinuitetsplaner och återstartstester

Backup restore är ett oerhört viktigt område som alla företag och föreningar måste tänka på . Hur länge kan ni vara utan ert datat och hur gammalt datat kan ni gåt tillbaka till ?

Efter att ha jobbat dagligen i 8 år som Disaster Recovery-tekniker och backup expert på SunGard Availabiliy Services kan jag vara mycket behjälplig med de flesta backuplösningar som finns på Windows, NetWare, Solaris samt Linux . Jag har unik kompetens på hur man återställer servrar, funktioner och nät.

Bland backuplösningar jag jobbat med både för återstarsttester och i dalig drift kan nämnas BackupExec, Symantec Netackup, VytalVault, Tivoli TSM BrighStor. Jag har troligen sett de flesta lösningar som finns på marknanden, både på små och stora företag.

Rutiner, dokumentation och incidenthantering

Utan en lättbegriplig men ändå detaljerad dokumentation och inventering kan det blir svårt att hantera IT miljön.
Jag kan hjälpa till med att skapa rutiner och dokumentation för att säkerställa en fungerande drift och ett fungerande tillvägagångsätt vid ett haveri. Här inåg även att ha en god inventering av hur miljön såg, övervakning och närliggande frågor.

Ingen kan planera för alla tänkbara avbrott men en god grundplan är en förutsättning för att snabbast möjligt kunna återkomma i produktion efter ett eventuellt haveri.
Frågan är enkel – Hur länge kan ni vara utan er IT och hur gammalt får data vara när det återläses?

Molntjänster

De senaste åren har jag varit mycket aktiv med molntjänster på Red Cloud IT där jag som molnarkitekt byggt, driftat och designat rCloud Office-lösning samt varit teknik-och konsultchef.
Jag är också delägare i Red Cloud IT men jag hjälper er att utvärdera även andra molntjänster och hjälper er att välja det som passar just er verksamhet.
Det finns många molntjänster och det gäller att välja precis rätt för just er verksamhet.
Jag kan även hjälpa er bygga en egen molnlösning, utvärdera andras eller hjälpa er migrera era applikationer från äldre servrar som t.ex. Windows Server 2003.

Verifiering, analyser och förbättringar av befinltiga lösningar och system

Jag kan hjälpa till med att verifiera befintliga lösningar , antingen genom gå igenom de lösningar ni har och föreslå förändringar eller göra fullständiga återläsningar av Era system för att säkerställa funktionalitet.
Jag är inte knuten till något företag eller produkt vilket gör mina analyser helt oberoende av andra leverantörer.
Jag hjälper er att planera era återstartstester och skriva återstartsplaner (s.k. DRP Disaster Recovery Planning) så de finns på plats när de behövs och ni kan minimera ert stillestånd. Jag kan också hjälpa er med praktiska återstartstester och backupövervakning.

Jag kan hjälpa till med planering och projektledning för installation och konfiguration av mailsystem, SQL, nätverk, brandväggar, VPN lösningar, övervakningar, DNSBlacklisting, antivirusskydd, affärssystem som Epicor Scala, Visma, Pyramid, CRM system .
All installation innehåller givetvis en god dokumentation och skulle behovet finnas kan jag hjälpa er att drifta systemen som second line.

IT drift, second och third line servertekniker

Då jag tidigare arbetat som konsult inom outsourcing är jag även kunnig inom drift, installation och support av företag och föreningar.
Jag har också varit del i driften av t,ex, SunGards online-backuptjänster där jag varit med om design, installation och drift.
Jag kan hjälpa till med er support och helpdesk på serversidan eller fungera som IT ansvarig /IT Chef / IT driftschef eller projektledare.

Hyr en IT chef , projektledare

Ibland behöver företag och organisationer någon som agerar IT Chef , projektledare eller IT ansvarig men behovet av att anställa någon är kanske inte så stort. Den ordinarie kan vara på semester, barnledig eller företaget är helt enkelt för litet för att anställa någon.
Lösningen är att hyra någon för ett antal timmar i veckan istället. Många saker kan göras på distans med moderna lösningar så var ni sitter geografiskt är kanske inte det viktigaste.

Skydda företagets identitet på Internet och SEO?

Jag hjälper er gärna med att se över hur ni syns på Internet och kommer med tips och råd om hur ni kan skydda ert varumärke och hur ni t.ex. kan använda Google Analytics för relevanta rapporter om besökare på er hemsida och får bättre leadsgenerering.
Jag hjälper er att sätta upp enkla verkyg för att få larm på om något förändras oväntat på er hemsida som kanske till följd av en hackerattack.
Jag hjälper er gärna också att övervaka detta och kommer med tips och förslag på hur ni kan synas bättre på t.ex. Google och t.ex. migrera er hemsida i HTML / PHP till en modernare, responsiv hemsida för mobila enheter.

IT säkerhet , analyser och intrångshantering

Grundläggande kontroller av nätverkssäkerheten, patchhantering, lösenordspolicies, intrångsförsök, backuprutiner o.s.v.

Hålla kurser och workshops

Jag har hållit kurser och workshops för externa företag om Disaster Recovery och backuper och kan även hålla kurser i t.ex. SEO (sökmotorpoptimering) och webövervakning.

Juha Jurvanen – Konsultprofil

En långt ifrån komplett CV / konsultprofil då en sån skulle bli orimligt lång efter 20 år som IT konsult men den ger ett hum om vad jag jobbat med innan.

Kontakta mig för ett möte

Backup/Restore och Disaster Recovery

Backup/restore, Disaster Recovery och kontinuitetsplaner

Hur ser backuptagningen ut med t.ex. Full, Differentiell och Inkrementell backup eller t.o.m kanske Delta / Block level? Vad är för- och nackdelarna med de olika sätten?
Vad är deduplicering? Vilka konsekvenser får det ? Räcker tiden för backupfönsret till?
Behövs en annan lösning eller går det att effektivisera det Ni har?
Att effektivisera och förbättra det ni har kan spara mycket tid och pengar.

Vad behöver vara med i backuperna ? Är det tillräckligt för att användas vid en restore av servern eller hela systemet?

Vad är minimum för backuper för att kunna återställa ett komplett systemhaveri eller bara delar av det?
Finns det dokumenterat HUR det ska göras? Har ni system som är beroende av varandra och i vilken ordning måste en restore göras för att så snabbt som möjligt att återgå till normal drift igen ? Hur fungerar just Ert server- operativ?
Microsoft Windows, Novell NetWare, SUN Solaris, Linux .. alla beter de sig olika vid restore.

Tar backuperna för lång tid och för mycket plats ? Går de att förbättra utan stora investeringar?

Vid återställnng av t.ex Microsoft Exchange bör man t.ex. exkludera vissa saker som kan “trassla” vid restore. Exemplen är många. Att backa onödigt mycket kostar bara tid, band och bandbredd. Går det kanske att effektivisera ? Backas en massa onödiga, privata filer som tar plats, tid och utrymme på backuperna?
Ska arbetstationer och laptops backas? Hur, isåfall?

Backupdrift och övervakning ? Backuploggar, vem läser dem och åtgärdar eventuella fel? Vem övervakar och tar ansvar för backupen?

Att missa felmeddelanden i backupen kan få ödesdigra konskvenser om Ert kritiska data inte finns med när det verkligen behövs. Enda sättet att veta är att göra en genomgång och analys av era backuper och göra en DR test (återstartstest).

Hur förvaras backuperna? Dags att tänka på online backuper?

Tänk på att allt Ert företagsdata ligger på banden/mediat och med rätt kunskap kan det användas fel.
och vem har tillgång till dem ? Och när ? Vem har ansvaret om de försvinner på vägen? Går det att lita på onlinebackuper ?

Vilka riktlinjer och IT policies gäller och hur följs de ?

Finns det policies uppsatta för överskrivning av banden ?
Hur långt tilbaka skall drifts-data kunna återläsas?
Hur länge arkiveras data ?
Vad säger lagen i Ert fall ?
Vilka riktlinjer är uppsatta från ledningen ?

I de här tidigare artiklarna har jag sammanställt några frågor och planer
Disaster recovery på svneska samt Grundmall för kontinuitetsplanering IT och återstartsplanering IT

Kontakta mig för hjälp med att se över era backuper och rutiner.

#konsultprofil för #itjobb #ituppdrag #konsultuppdrag JufCorp – Juha Jurvanen

Jufcorp hemsida

Till JufCorps hemsida

Ibland roar jag mig med att lägga upp den här , till stor del för jag är intresserad av hur Google indexerar saker och hur SEO fungerar, därav en del upprepningar av t.ex. CV.
För att få en bra och vettig statistik för sökmotoroptimerong måste man testa sig fram, precis som med allt annat inom IT egentligen.

1.Sätta sig in i hur det fungerar.
2 Planera.
3 Testa.
4.Testa igen.
5.Verifiera
6.Testa 🙂

Konsultprofil / CV IT konsult inom backup, IT säkerhet, IT drift och molntjänster – Juha Jurvanen

Juha Jurvanen

Juha är en seniorkonsult med 16 år erfarenhet inom IT branschen. Juha har både bredd och djup inom t.ex. backup, disaster recovery, serverdrift, IT säkerhet och molntjänster.
Juha har stor erfarenhet av drift och problemsökning i stora datamiljöer. Juha har specialistkompetens inom backup och restore området och serverdrift och är även initiativtagare till Syspeace samt molnarkitekt där han byggt en a Sveriges första molntjänster.
Juha skriver även om serverfrågor i bloggarna http://jufflan.wordpress.com samt http://syspeace.wordpress.com

Mycket kort urval av kompetenser

Backup / restore – Drift, utredningar, design, tester, onlinebackuper
 Serverdrift . second/third line främst inom Microsoft men även Linux, NetWare, Solaris
 IT säkerhet – intrångshantering, brandväggar, autentisering, antivrus, patch management och incident management, ITIL, kontinuitetsplaner för IT
 Molntjänster, integration, design, drift, hybridmolm
 Applikationsdrift och felsökning, installation och migrering som t.ex.Exchange, Lotus Domino, Sharepoint, Active Directory, Visma, Pyramid, SQL Server
 Övervakning av servernät och nätverk som t.ex. OP5, HP Insight Manager, SNMP o.s.v
 Helpdesk, first line och support för molntjänster samt Syspeace

Några uppdrag

Syspeace (http://www.syspeace.com)
Att utveckla och skapa en enkel och fungerande intrångshanterare för Windows servrar.

Drift an NetBackup lösning för c:a 2000 servrar hos svensk mydnighet

Drift av Citrix / XenAPP lösning för privat vårdföretag på c:a 600 anställda.

Design och lösning förslag för DR lösning för VMWare med hjälp av Legato för stort teknikföretag

Avancerad felsökning av felaktigt uppsatta Active Directory Trusts åt kund.

Behälplig vid drift av miljö på 200 Servrar åt kund. Windows Server 2003, Windows Server 2008 / R2 , Exchange, Citrix, VMWare.

IT arkitekt. projektledare samt konsultchef och teknikchef för molntjänsterna på Red Cloud IT

Oberoende konsult vid hjälp av upphandling av backupsystem för företa inom gruvnäringen
I uppdraget ingick att granska anbud och tekniska lösningar.

Migrering av Novell Netware miljö till Windows 2008 AD för olika kunder

Test och implementation av privat molntjänst åt en av AP Fonderna

Uppdrag att skapa en BCP (Business Coninuity Plan) och DR Plan (Disaster Recovery plan ) för en av AP fonderna.

Effektivisering av backupmiljö på företag för kontamhenatering

Effektivisering och genomgång av backupmijö inom Public Service

Utvärdera och implementera övervakningssystem hos SunGard.Till sist föll valet på Op5 som är baserat på Nagios

IT arkitekt och second line för SunGards online backuptjänst, VytalVault baserat på i365s InfoStage

Var behjälplig vid DR test av servermiljön på ett av våra större fackförbund.

Uppdrag att planera och genomföra migrering från Lotus Notes till Microsoft Exchange hos kund på c:a 50 användare.

Tekniskt ansvarig vid byte av Internet-leverantör för kund med kontor på 21 platser i landet. Second line och kontaktpoerson för kontoren och gentemot leverantören.

Anställningar / Eget

JufCorp

2007 –
Red Cloud IT 2009-2011
SunGard 1998 – 2007
Enator 1996-1998

Kontakta mig gärna för uppdrag? Antingen genom formuläret nedan eller klicka här

[contact-form-7 404 "Not Found"]

Skillnaden mellan BCP och DR / DRP ?

De som följt de saker jag skriver vet att jag tycker om olika former av övervakning i olika sammanhang vad gäller IT frågor och servrar, hemsidor och loggar.

Ett resultat av det är att jag brukar hålla på koll på t.ex. vilka söktermer folk använt för att hitta till de saker jag skriver eller varifrån de kom dvs vilka sidor eller rent geografiskt. det kan ha sina fördelar att veta i samband med en kampanj t.ex.

En sökning som hade hamnat hos mig idag var just rubriken. “Vad är skillnaden mellan BCP och DR?”

Kort och förenklat uttryckt.
BCP är Business Conituiity Planning och är en övergripande plan som handlar om hur vi får vår verksamhet att fortsätta fungera i olika tänkta olyckliga scenarion.

Säg t.ex. en större händelse som påverkar vår verksamhet (en skandal i styrelsen, anklagelser om fusk o.s.v., leverantörer sluta leverera saker till oss, ett längre stillestånd, strejk o.s.v. )

Hur fortsätter vi vår verksamhet och har rätt skadekontroll? Har vi gjort våra s.k SWOT analyser som belyser våra olika styrkor och svagheter och har en plan för att hantera om något händer i våra svaga områden ? En BCP är alltså en kontinuitetsplan för verksamheten och företag i stort. Den innehåller också strategier och processer för kontakt med media t.ex.

En DRP är mera en praktisk beskrivning av vad som ska göras om någon oväntad teknisk katastrof inträffar (serverhaveri, datahallsbrand o.s.v. ) , oftast menar man här tekniska planer och beskrivningar av hur system ska tas tillbaka, var de ska sättas upp, hur backuperna ska användas o.s.v.

De här två sakerna går onekligen lite hand i hand såklart men, som sagt , den ena är en mera övergripande sak och den andra kanske kan kallas en slags praktisk handbok vid en katastrof.

Juha Jurvanen

Senior IT konsult inom backup, IT drift, IT säkerhet och molntjänster

Säkerhet och Molntjänster. Aktuellt idag. Ännu mer aktuellt i framtiden!

Säkerheten i Molnet

Red Cloud IT fortsätter att höja ribban för din säkerhet i molntjänster !

Säkerhet i molnet diskuteras ständigt.

Faktum är att i de flesta system finns alltid möjligheten för en administratör att se data. Oavsett leverantörens storlek eller var data finns .. Ett problem som kan vara svårlöst i många fall när man har väldigt höga krav på sekretess och företaghemilgheter om man tittar på några av de molntjänster och lösningar som finns på markanden idag.

Det här har vi funderat lite kring och tagit fasta på.

Sedan lång tid tillbaka kan våra kunder utöka sitt skydd genom att kryptera sitt data, antingen enskilda filer eller hela kataloger.

Den krypterade datan är så säker att inte den ens kan dekrypteras av de högst behöriga teknikerna eller administratörerna hos Red Cloud IT.
En kund som kyrperar sitt data är den enda som kan öppna och läsa sina filer.

Red Cloud IT har även tagit fasta på andra aspekter av säkerhet såsom t.ex. generationshantering och backuper så att användarna själv kan ta tillbaka filer de råkat skriva fel i eller råkat radera av misstag. Utan att behöva kontakta någon support eller vänta i timmar på IT avdelningen. Att återläsa filer eler kataloger från två timmar tillabka , fyra timmar tillbaka o.s.v. sker med ett enkelt högerklick på katalogen där användaren själv väljer från vilken generation datat ska återskapas.

Grundmall för kontinuitetsplanering IT och återstartsplanering IT

konsult inom backup It säkerhet molntjänster och infratruktur Kontakt

Grundmall för kontinuitetsplanering IT och återstartsplanering IT

Den här planen är en sak jag hittat på nätet och den går ner på detaljnivå i vissa frågor men kan vara en bra start för alla företag och organisationer.
En bra början är alltid att inleda med en övergripande kontinuitetsplan i korta rubriker.

När man verkligen slår sig ner och börjar arbeta med de här frågorna inser man snabbt att det är ett stort arbete men om man har det på plats kan ett stillestånd efter ett haveri bli betydligt kortare när något inträffar och det finns klart definierade roller och ansvarsområden kring hur katastrofen skal hanteras.

Den här mallen är alltså bara en grund egentligen och behöver anpassas, bearbetas för att passa just er verksamhet och er behov men den är en intressant läsning att utgå ifrån. Delar av det är inte relevant kanske för alla företag och andra delar saknas helt

Från den här planen kan t.ex. tekniska återstartsbeskrivningar utgå och annan relevant dokumentation.

Jag hjälper er gärna med att tänka igenom såna här frågor och agerar gärna projektledare för de här frågorna, särskilt kring den tekniska återstartplanen med backuper och policies kring IT hanteringen som t.ex. hur ni rent tekniskt ska kunna få ut informationen snabbt o.s.v.

Välkommen att kontakta mig

Grundmall för koninuitetsplan och återstartsplan

1.0

GRUNDMALL FÖR KONTINUITETSPLAN / ÅTERSTARSTPLAN

0 VERSIONS- OCH SEKRETESSHANTERING 3
1 VILLKOR FÖR AKTIVERING AV KONTINUITETSPLAN 3
1.1 KATASTROF 3
1.2 ALLVARLIGT AVBROTT 3
2 INLEDANDE AKTIVITETER 3
2.1 ANALYS AV STÖRNINGEN/AVBROTTET 3
2.1.1 Procedur för upptäckt/identifiering av avbrottets omfattning 3
2.2 LARM 4
2.3 KATASTROFGRUPPEN 6
3 ÅTGÄRDER – AVBROTTSPLAN 8
3.1 CHECKLISTOR VID OLIKA TYPER AV INCIDENTER 8
3.1.1 Systemfunktion utslagen 8
3.1.2 Sabotage 8
3.1.3 Fysisk driftsmiljö 9
4 AKTIVERING AV RESERVDRIFT/RESERVRUTIN 11
4.1 SYFTE MED RESERVDRIFT 11
4.2 BESLUT OM FÖRBEREDELSER AV RESERVDRIFT/RESERVRUTIN 11
4.3 PROJEKTLEDARE FÖR RESERVDRIFT/RESERVRUTIN 11
4.3.1 Instruktioner för projektledaren 11
4.3.2 Loggbok 11
4.4 FÖRBEREDELSER FÖR RESERVDRIFT/RESERVRUTIN 12
4.5 BESLUT OM ÖVERGÅNG TILL RESERVDRIFT/RESERVRUTIN 12
4.6 RESERVDRIFT OCH RESERVRUTINER 12
4.6.1 Servicenivå, prioriteringar 12
4.6.2 Utformning av reservdrift 12
4.6.3 Utformning av reservrutiner 13
5 ÅTERGÅNG TILL NORMAL DRIFT 14
5.1 CHECKLISTOR FÖR ÅTERSTART AV VERKSAMHET 14
5.1.1 Leverantörsavtal 14
5.1.2 Verksamheten 14
5.1.3 Utanför verksamheten 14
5.2 DOKUMENTATION/CHECKLISTOR 14
5.2.1 Bibliotek/filer/databaser m.m. för säkerhetsarkivering/återläsning 14
5.2.2 Utrustning 15
5.2.3 Programvaror 15
5.2.4 Ordningsföljd vid uppstart och nedtagning av systemet 15
5.2.5 Kontrollpunkter under återstart 15
5.2.6 Informationsflöde 15
5.2.7 Konfigurationslistor 15
5.2.8 Kommunikation 16
5.2.9 Samband 16
5.2.10 Lagstiftning 16
5.3 BACKUPHANTERING 16
5.4 ÅTERLÄSNING 16
5.5 UNDERHÅLLSRUTINER 17
5.5.1 Revidering och underhåll av kontinuitetsplanen 17
5.5.2 Utbildning och övning 17
5.5.3 Distribution 18
6 INFORMATIONSSPRIDNING 19
6.1 INFORMATIONSSPRIDNING OCH KANALER FÖR DETTA 19
6.2 INTERNT 19
6.2.1 Ledning 19
6.2.2 Användare 20
6.2.3 IT-avdelningen 20
6.2.4 Växel 20
6.3 LEVERANTÖRER 21
6.4 VÅRDGRANNAR 21
6.5 SAMARBETSPARTNERS 21
6.6 ALLMÄNHETEN 21
7 PERSONUPPGIFTER 22

0 Versions- och sekretesshantering
Version Sida Kapitel Datum Beskrivning Namn

Denna dokumentation skall hanteras under sekretess, vilket innebär att utlämnande av uppgifter enbart skall ske till behöriga personer. Kopiering får endast ske efter godkännande av systemägaren.
1 Villkor för aktivering av kontinuitetsplan
Kontinuitetsplanen ska omfatta de åtgärder som ska säkerställa en kontinuerlig drift vid allvarligare avbrott eller störningar.

Planen ska aktiveras när en katastrof eller ett allvarligt avbrott har inträffat eller sannolikt kommer att inträffa.
1.1 Katastrof
Definitioner för vad som är en katastrof,
1.2 Allvarligt avbrott
Defintion av en allvarlig händelse.
2 Inledande aktiviteter
2.1 Analys av störningen/avbrottet
Innan åtgärderna för att återskapa påbörjas, bör katastrofgruppen genomföra en snabb analys av omfattning och vilka konsekvenser avbrottet/störningen kan orsaka samt analysera var/varför avbrottet/störningen uppstått.

2.1.1 Procedur för upptäckt/identifiering av avbrottets omfattning
Hur bedömning görs för att bedöma avbrottstid och vilka som berörs.
2.1.1.1 Process för upptäckt av avbrott
Olika källor som kan upptäcka avbrott, samt informationsflöden vid avbrottsrapportering:

1. LARM via övervakning
Larm och åtgärd vid larm finns beskrivet i Driftdokumentationen som finns placerad XXX

2. Driftavdelning för systemet
Avbrott p g a:
1 Exchange tjänster och andra tjänster som går ned.
2 Prestandaproblem: CPU, minne, disk
3 Högt belastade e-post köer
4 Hårdvarufel
5 Fel i operativsystem
6 Fel i applikationer

3. E-post användare  IT-avdelningen  Driftavdelning för systemet

4. Teknisk Drift/Nätgruppen
Avbrott p g a:
1 Fel i nätverkskomponenter, t ex switchar, routrar, brandvägg
2 Kabelfel

2.2 Larm
Larm ska ske när det uppstått en störning eller ett avbrott där åtgärden inte hanteras enligt normal drifthantering och/eller omfattningen ej omedelbart kan bedömas. Systemansvarig är ansvarig för att larma.

Larm ska ske till:
• X –person (t ex systemförvaltare) eller
• Y-person eller
• Z-person
dessutom ska IT-akuten alltid larmas.

Informationen bör innehålla uppgifter om:
1 Vad som inträffat
2 Person-/materiella skador
3 Åtgärder som har vidtagits
4 Hur länge avbrottet beräknas pågå
5 Vem som upptäckte störningen
6 Vem som ”äger” ärendet

Den person som tar emot larmet kontrollerar om kontinuitetsplanen ska aktiveras enligt villkoren nedan. Om kontinuitetsplanen ska aktiveras ska katastrofgruppen sammankallas snarast.

2.2.1.1 Definition av avbrottets omfattning
Vid avbrott ska följande identifieras och beskrivas:

TID När inträffade avbrottet?
Hur lång tid beräknas avbrottet vara?

VEM upptäckte störningen/avbrottet?

VAD omfattar avbrottet?
3 Tjänst
4 Maskin
5 Applikation
6 Nätverkskomponent
7 Datahall

Specificera den funktionalitet som inte fungerar p g a avbrottet.
Specificera eventuella person- samt materiella skador.

VILKA drabbas av avbrottet?
1 Användare (antal)
2 Andra IT system inom
3 Teknisk Drift/Nätgruppen
4 Externa leverantörer/kunder

FORTSATT ARBETE
1 Informera systemförvaltare och systemansvarig
2 Vilka åtgärder har hittills vidtagits?
3 Specificera vem/vilka som ansvarar för att återställa de olika funktioner som avbrottet berör.
4 Vem/vilka har huvudansvaret samt samordnande roll för de återställande aktiviteterna?
2.2.2 Interna och externa faktorer
2.2.2.1 Tekniska faktorer
2.2.2.2 Tekniska faktorer
Kontakt med teknisk drift och avdelningen för nät och kommunikation.
Namn Roll
A.A Teknisk drifts beredskap
B.B Brandvägg/kommunikation
C.C Näts beredskap
D.D Samordning HW-Avtal
E.E Systemansvarig

För kontaktinformation se kapitel Personuppgifter.
2.2.2.3 Beroenden och avtal
Hänsyn ska tas till externa och interna beroenden, krav, åtaganden och avtal. En hänvisning till var avtal finns bör finnas med.
Ett scenario kan vara att information inte kan skickas till vårdgrannar som nödvändigt. Då ska beroendet till de vårdgrannarna anges här. Detta ska underlätta att bedöma konsekvenserna av avbrottet och därmed de åtgärder som behövs.
2.3 Katastrofgruppen
De personer som ska vara med och ta beslut om alternativa rutiner, återstart och eventuella korrigerande åtgärder ska finnas med i gruppen.
En katastrofgrupp ska inrättas med i förväg utsedda medlemmar, inklusive ersättare.

Namn Roll i katastrofgruppen
A.A Systemägare/systemförvaltare
B.B Ansvarig för IT-verksamheten
C.C Ansvarig för IT-drift, egen personal
D.D Projektledare för reservdrift
E.E Ansvarig för informationspridn.
F.F IT-säkerhetsansvarig eller säkerhetsansvarig

För kontaktinformation se kapitel Personuppgifter.

Katastrofgruppen har det övergripande ansvaret och ska fatta beslut om bland annat:
1 förbereda reservdrift
2 övergå till reservdrift
3 övergå till normal drift
4 information till användare
5 övergång till alternativa rutiner, manuella eller IT-baserade

3 Åtgärder – Avbrottsplan
3.1 Checklistor vid olika typer av incidenter
Åtgärder som görs efter ett avbrott/incident.
3.1.1 Systemfunktion utslagen
3.1.1.1 Hårdvara
Se Checklistor
3.1.1.2 Mjukvara
Se checklistor
3.1.2 Sabotage
3.1.2.1 Virus
Vid misstanke om smitta med datavirus eller motsvarande gäller följande:
1 Bedöm om allt ska tas offline eller bara vissa delar.
o Ta det aktuella offline.
2 Lokalisera vad som är smittat och vad smittan är.
Frågor som kan hjälpa till vid bedömningen är:
o Vilken klient/server har uppfört sig konstigt, vilket gjorde att virus misstänktes?
o Hur kan klienten/servern blivit smittad?
o Vilka maskiner kan klienten/servern smittat vidare?
3 Kontrollera om uppdateringar av virusskyddet som är aktuella för viruset finns hos leverantör.
4 OM uppdateringar av virusskyddet finns, installera dessa.
o Scanna servrar och klienter med det uppdaterade virusskyddet.
o De servrar och klienter som inte är infekterade kan tas upp på nätet igen.
o OM programvara för att tvätta bort viruset finns:
1. Tvätta infekterade servrar
2. Tvätta infekterade klienter
Allt eftersom maskinerna är tvättade kan de tas upp på nätet igen.
o OM INTE programvara för att tvätta bort viruset finns får de infekterade maskinerna vara offline tills programvaran för att tvätta finns som en uppdatering av antivirusprogrammet eller som en separat programvara.
o Om viruset har exekverat på vissa maskiner och dessa inte går att tvätta:
 Formatera diskarna
 Installera om operativsystem och applikationer
 Återläs ev data.
 Scanna.
 Ta upp på nätet.
5 OM INTE uppdateringar av virusskyddet finns:
o De filtyper som är aktuella för viruset kan stoppas i filter.
o De maskiner som helt säkert är oinfekterade kan tas upp på nätet igen.
o Vänta tills uppdateringar av virusskyddet kommer.
Orientera ledningen om omfattning och hur lång tid arbetet bedöms ta.
3.1.3 Fysisk driftsmiljö
3.1.3.1 Brand

I händelse av brand gäller följande:
1. RÄDDA
a. Rädda dem som befinner sig i uppenbar fara, är skadade eller på annat sätt befinner sig i nödläge.
b. Om branden bedöms kunna bekämpas, ska släckning prioriteras.
Släckutrustning som får användas i datorrummet är kolsyrehandbrandsläckare. Dessa förvaras i datorrummet till höger om dörren. Utanför datorrummet i korridoren 15 meter från datorrummet.
1. LARMA
c. Räddningstjänsten genom larmknappen (Krossa glaset och tryck på knappen).
d. SOS tel 112. Kontrollera att larmet är utlöst.

Meddela kortfattat:
1 Vad som hänt
2 Var det brinner, hus, vån, avd
3 Om det finns instängda människor
4 Vem du är, var du ringer ifrån, namn, telnr
Om möjlighet finns, möt Räddningstjänsten
2. VARNA
g. Varna dem som akut kan komma att hotas av branden eller på annat sätt utsättas för fara.

3. SLÄCKA
h. Försök släcka/begränsa branden utan att utsätta dig själv för fara.
i. Om branden bedöms vara för omfattande utryms datorrummet.
j. Återsamling efter utrymning sker på gården utanför huvudentrén.
k. Så snart tillfälle ges kontakta katastrofgrupp.
3.1.3.2 Elavbrott
XXX har en UPS som räcker i 15 minuter vid full belastning.

Vid elavbrott gäller följande:
1 Larm går till UPS-ansvarig.
2 UPS-ansvarig försöker kontrollera avbrottets anledning och bedömer konsekvenserna.
3 Så snart tillfälle ges kontakta Katastrofgrupp-System E-postkatastrofgrupp.
4 Nedtagning av utrustning enligt lista och starta ev reservdrift.

4 Aktivering av reservdrift/reservrutin
4.1 Syfte med reservdrift
Reservdriften ska vidmakthålla bästa möjliga funktion utan att äventyra eller försena återgången till normal drift.
4.2 Beslut om förberedelser av reservdrift/reservrutin
Katastrofgruppen beslutar om förberedelse för övergång till reservdrift/reservrutin.

För följande frågor ska beslut fattas av katastrofgruppen:
1 göra större investeringar
2 disponera personal utöver ordinarie arbetstid
3 beslut om övergång till reservdrift/reservrutin
4 avsluta reservdriften för återgång till normal drift
5 öppethållande
6 information
7 delegera ansvar och befogenheter till projektledaren för reservdrift
4.3 Projektledare för reservdrift/reservrutin
Dennes uppgift är att leda och samordna arbetet med förberedelser och genomförande av reservdrift/reservrutin.
4.3.1 Instruktioner för projektledaren
Projektledarens uppgifter är att:
1 fördela arbetet till olika arbetsgrupper
2 flera gånger dagligen lämna lägesrapporter till katastrofgruppen och IT-akuten
3 hålla regelbundna möten för att informera arbetsgrupperna om arbetsläget
4 följa upp viktiga beslutspunkter för respektive arbetsgrupp
5 samordna arbetet mellan arbetsgrupperna så att åtgärderna vidtas i rätt ordning
4.3.2 Loggbok
En loggbok ska föras över alla åtgärder som vidtas.För varje aktivitet ska loggen innehålla datum, tidpunkt, ansvarig och namnet på den som skrivit in aktiviteten.

4.4 Förberedelser för reservdrift/reservrutin
Säkerställ viktig infrastruktur och logistik som:
1 Lokal
2 Utrustning,
3 Säkerhetskopior
4 Elförsörjning
5 Klimatförsörjning
6 Kommunikationsanslutningar
7 Förbrukningsmaterial
8 Papper
9 Blanketter
10 Övrigt
11 Manualer
12 Tillträdesskydd
13 Telefonförbindelse
14 Fax
15 Säkerhetsarkiv
16 Möjlighet att servera mat till personalen
17 Övernattningsmöjligheter
4.5 Beslut om övergång till reservdrift/reservrutin
Beslut om övergång till reservdrift/reservrutin fattas av katastrofgruppen.
4.6 Reservdrift och reservrutiner
4.6.1 Servicenivå, prioriteringar
Respektive verksamhetsansvarig fastställer på vilken servicenivå som verksamheten ska upprätthållas vid en katastrofsituation.
Prioritering av verksamheter:
1. X
2. Y
3. Z
Ansvarig för ……………………verksamheten är ………………….
4.6.2 Utformning av reservdrift
Styrande förutsättningar för agerandet vid reservdrift är sannolikt de prioriteringar som ledningen gör av olika delverksamheter.
Driftrutiner för en situation med reservdrift bör utgå från de ordinarie rutinerna. Kraven på att snabbt få igång en reservdrift kan dock tvinga fram lösningar som avviker från ordinarie rutiner.
Därför är det viktigt att dokumentera reservdriftens:
• Driftrutiner
• Konfigurationer
• ………………………….
4.6.3 Utformning av reservrutiner
För de verksamheter som har prioriterats utformas här aktuella reservrutiner.
Utformningen ska bygga på inget eller partiellt IT-stöd. Tillgängligheten (t ex till annan maskinell utrustning, fax m.m.) samt kompetenskrav ska fastställas för rutinerna.
1 Exempel på tekniker som kan användas vid utformning av reservrutiner är:
2 Stand alone PC
3 Listor uttagna i förväg
4 Manuella rutiner
5 Fax-användning
Ange de negativa följder som uppstår för verksamheten då reservrutinen används.

5 Återgång till normal drift
Katastrofgruppen fattar beslut om att:
1 reservdriften avslutas för övergång till normal drift.
2 avveckling av projektet för reservdriften

Nedan finns dokumentation som ska hjälpa till i arbetet för återgång till normal drift.
5.1 Checklistor för återstart av verksamhet
Återställande rutiner för att återuppbygga och återgå till normal drift.
5.1.1 Leverantörsavtal
5.1.2 Verksamheten
5.1.3 Utanför verksamheten
5.2 Dokumentation/checklistor
Information om systemet, bl a systembilden, förväntade avbrottstider och beroenden till andra system.
Dokumentation över systemets uppbyggnad och beståndsdelar ska omfatta datamängder (databaser, filer), programvara, utrustning, kommunikationsvägar, konfiguration som är nödvändiga för den fortsatta driften.
5.2.1 Bibliotek/filer/databaser m.m. för säkerhetsarkivering/återläsning
Denna dokumentation består av en beskrivning av applikationens IT-mässiga uppbyggnad och finns enligt följande:
Hänvisning:
• operativsystem, Driftdokumentationen, kap. 6.4
• bibliotek, __________
• procedurer, __________
• program, __________
• filer, __________
• databaser, __________
• databashanterare, __________
• kommunikationsprogram, __________
• behörighetskontrollsystem __________
• krypteringsprogram, __________
• sigilleringsprogram. __________

Dokumentationen förvaras …………………….
5.2.2 Utrustning
Grafisk presentation:
• beståndsdelar
• funktionsbeskrivning
5.2.3 Programvaror
Grafisk presentation:
• beståndsdelar
• funktionsbeskrivning
5.2.4 Ordningsföljd vid uppstart och nedtagning av e-post systemet
5.2.5 Kontrollpunkter under återstart
5.2.6 Informationsflöde
Grafisk presentation:
• internt
• externt
5.2.7 Konfigurationslistor
Dokumentation över datasystemets konfiguration finns enligt följande:
• operativsystemet __________
• applikationen __________
• nätverket __________
• kommunikationsutrustning __________
• behörighetskontrollsystemet __________
• brandväggar __________
5.2.8 Kommunikation
5.2.9 Samband
5.2.10 Lagstiftning
De lagar som gäller under en katastrof. Här kan även lagar som är viktiga för systemet finns med. Exempel är PuL, tryckfrihetsförordnigen och sekretesslagen.
Följande lagar ställer krav på XXX-systemet:
1 Tryckfrihetsförordningen
o Offentlighetsprincipen
2 Arkivlagen
o Beslut om vad som ska sparas och val av media för långtidslagring

Hantering av patienter och personuppgifter ställer även följande lagar krav på XXX-systemet:
1 Hälso- och Sjukvårdslagen
o Sjukvårdsuppgifter
2 Sekretesslagen
o Patient- och personuppgifter
3 PUL
o Patient- och personuppgifter
o Vårdregisterlagen

5.3 Backuphantering
Säkerhetskopior ska tas med en sådan frekvens att ingen allvarlig skada uppstår om information på original datamedia och minnesenheter förloras. Säkerhetskopior ska förvaras på annan plats än original eller i sk datamediaskåp.
5.4 Återläsning

5.5 Underhållsrutiner
5.5.1 Revidering och underhåll av kontinuitetsplanen
Kontinuitetsplanen bör revideras en gång per år om inte annat beslutats.

Grund för revideringsarbete är följande:
1 organisationsförändringar
2 nya versioner av programvara, hårdvara m.m.
3 förändringar i kontaktinformation
4 förändringar i reservdriftsutrustning
5 förändringar i avtal
6 förändringar i lagkrav
7 rapporter från genomförda tester och övningar
8 …
Ansvarig för revidering är XXX.

Den reviderade upplagan av kontinuitetsplanen distribueras enligt punkten 5.5.3.
5.5.2 Utbildning och övning
För att verksamheten ska kunna bedrivas under någon form av katastrof måste berörd personal få utbildning och övning inom:

• Krishantering
• Provdrift på det alternativa driftstället
• ……………………

För planering och genomförande av utbildning ansvarar xxx.

För planering och genomförande av övningar ansvarar xxx.

Övningar ska genomföras x gånger per år.

5.5.3 Distribution
Planen är distribuerad till:
Namn Plannummer
Datahallen 1
Säkerhetschefen 2
Säkerhetsskåp 3
Receptionen 4


6 Informationsspridning
Ansvarsområden, organisation och telefonlista.
6.1 Informationsspridning och kanaler för detta
Informationsspridning är en särskilt viktig ledningsfråga vid alla typer av katastrofsituationer.

’Ansvarig för informationsspridning’ är en person i katastrofgrupp som är ansvarig för kontakter med allmänheten och andra externa och interna parter.

All informationsspridning ska föregås av beslut i katastrofgruppen.

Intern informationsspridning sker genom X

Information ska ges till följande informationsmottagare:
1 Internt
2 Kunder, externa parter
3 Partners
4 Allmänheten, t.ex. via media
6.2 Internt
6.2.1 Ledning
Namn Befattning
A.A Chef
B.B Programansvarig IT
C.C Chef Informatörsgruppen
D.D Chef LRÖ
E.E IT-säkerhetschef

F.F
G.G
H.H Chefläkare:
US
ViN
LiM

6.2.2 Användare
Användare informeras via intranet X
Om Intranät är utsaget meddelas användare via telefon eller SMS

IT-samordnare och IT-resurspersoner informeras enligt gällande lista.
6.2.3 IT-avdelningen
Externt telefonnummer är X
Internt telefonnummer är X.

IT-acdelningen ska medverka genom att:
1 ta emot alla samtal som kommer från kunderna
2 initialt vara mycket restriktiva med att vidarebefordra samtal
3 informera om eventuella tidsintervall per kund för åtkomst till applikationen p.g.a. kapacitetsbrist
4 inrätta en automatisk telefonsvarare som uppdateras löpande
6.2.4 Växel
Externt telefonnummer är X
Internt telefonnummer är X

Växeln behövs om telefonnumren på listan inte är aktuella och även som informationsmottagare och informationsgivare för allmänheten, t ex för att meddela vilka IT-tjänster som har avbrott och som slår mot allmänheten, med förslag på alternativa lösningar för dessa IT-tjänster.

6.3 Leverantörer
Information ska ges till leverantörer av:
• utrustning _________________
• applikationer _________________
• kommunikationstjänster _________________
• nättjänster _________________
• transporter _________________
Övergång till reservdrift medför att organisationens leverantörer direkt eller indirekt kommer att påverkas. Det är därför nödvändigt att informera dessa om att situationen inträffat samt vad detta innebär för deras del som t.ex. nya rutiner. Informationen bör endast innehålla det som är relevant för dessa parter.

Företag Kontaktperson Telefonnr Område
AAA A.A xxxx Routrar,
BBB B.B xxx Kabeldragning

6.4 Kunder , externa parter

6.5 Samarbetspartners och kontaktuppgifter
Specialist på DR scenarion : JufCorp juha.jurvanen@jufcorp.com
Hårvdarulevernatör : X

6.6 Allmänheten

7 Personuppgifter

Namn Roll i Systemkatastrofgrupp e-post Telefonr., minicall Privata nummer Privat e-post
A.A Systemägare/systemförvaltare
B.B Ansvarig för IT-verksamheten
C.C Ansvarig för IT-drift, egen personal
D.D Projektledare för reservdrift
E.E Ansvarig för informationspridn.
… Teknisk drifts beredskap
Brandvägg/kommunikation
Näts beredskap
Samordning HW-Avtal
Systemansvarig
Teknisk drifts beredskap
Brandvägg/kommunikation
IT-säkerhetsansvarig eller säkerhetsansvarig

LOGGBOK

Datum Tidpunkt Händelse/åtgärd Ansvarig Inskriven av ..

……. …………………….

Frågor kring backup – taget från http://www.jufcorp.com

Jufcorp - Senior IT konsult inom backup, IT säkerhet , IT drift och molntjänster

Till JufCorps hemsida

Hur tas era backuper ? Finns det relevant backup dokumentation? Tänkt på Disaster Recovery planen, återstartsplanen?

Hur ser backuptagningen ut med t.ex. Full, Differentiell och Inkrementell backup eller t.o.m kanske Delta / Block level? Vad är för- och nackdelarna med de olika sätten?
Vad är deduplicering?
Vilka konsekvenser får det ?
Räcker tiden för backupfönsret till?
Behövs en annan lösning eller går det att effektivisera det Ni har?
Att effektivisera och förbättra det ni har kan spara mycket tid och pengar.

Är det tillräckligt för att användas vid en restore av servern eller hela systemet?

Vad är minimum för backuper för att kunna återställa ett komplett systemhaveri eller bara delar av det?
Finns det dokumenterat HUR det ska göras?
Har ni system som är beroende av varandra och i vilken ordning måste en restore göras för att så snabbt som möjligt att återgå till normal drift igen ?
Hur fungerar just Ert serveroperativ?
Microsoft Windows, Novell NetWare, SUN Solaris, Linux, alla beter de sig olika vid restore.

Tar backuperna för lång tid och för mycket plats ?

Vid återställnng av t.ex Microsoft Exchange bör man t.ex. exkludera vissa saker som kan “trassla” vid restore. Exemplen är många. Att backa onödigt mycket kostar bara tid, band och bandbredd. Går det kanske att effektivisera ?
Backas en massa onödiga, privata filer som tar plats, tid och utrymme på backuperna?
Ska arbetstationer och laptops backas? Hur, isåfall?

Backuploggar, vem läser dem och åtgärdar eventuella fel? Vem övervakar och tar ansvar för backupen?

Att missa felmeddelanden i backupen kan få ödesdigra konskvenser om Ert kritiska data inte finns med när det verkligen behövs. Enda sättet att veta är att göra en genomgång och analys av era backuper och göra en DR test (återstartstest)

Hur förvaras backuperna?
Dags att tänka på online backuper?

Tänk på att allt Ert företagsdata ligger på banden/mediat och med rätt kunskap kan det användas fel.
och vem har tillgång till dem och när ?
Vem har ansvaret om de försvinner ?

Vilka riktlinjer och IT policies gäller och hur följs de ?
Finns det policies uppsatta för överskrivning av banden ?
Hur långt tilbaka skall drifts-data kunna återläsas?
Hur länge arkiveras data ?
Vad säger lagen i Ert fall ?
Vilka riktlinjer är uppsatta från ledningen ?

JufCorp kan erbjuda Ert företag unik backupexpertis med över 16 års praktisk erfarenhet inom backup/restore och Disaster Recovery-området och återstartsplanering.

Copyright © 2009 JufCorp.com