Archives for itdrift

#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 to=’juha.jurvanen@jufcorp.com’ subject=’Kontakt från WordPress’][contact-field label=’Namn’ type=’name’ required=’1’/][contact-field label=’Email’ type=’email’ required=’1’/][contact-field label=’Företag’ type=’text’/][contact-field label=’Website’ type=’url’/][contact-field label=’Förfrågan’ type=’textarea’ required=’1’/][/contact-form]

How quickly new servers are found and targeted on the Internet

Just a short post on how quickly servers are found on the Internet and how quickly they are attacked with brute force and dictionary attacks.

On Tuesday morning (this week) , a new server was installed for a new customer. The server became accesible to me on Tuesday afternoon.
On Wednesday I did my stuff on it (securing services , setting up backups and so on) and also installed Syspeace (which I always do btw since it should be a part of every servers baseline security in my opinion).

At 21:37 the first attack came a knocking on the door.

This means that the server had not been accessible for more than 36 hours and was already targeted from an attacker.

The IP address originated from the US this time and I disregarded it since the email alert from Syspeace automatically showed me the username, DNS name and countryu of origin.
Not worth the trouble pursuing in this case. Proably just a part of a botnet but still, it’s interesting to see how quickly it actually happens.

If you want to know if you’re attacked, simply turn logging on you server and have a look.

by Juha Jurvanen – JufCorp

Senior IT konsult inom backup, IT drift, IT säkerhet och cloud tillgänglig för uppdrag

En ny konsult profil jag skrev för ett tag sen, med viss inriktning för ett uppdrag som var just Citrix intriktat. Något nerkortad.

Juha Jurvanen

1968-12-31

Titel

Senior IT konsult inom backup, IT drift, IT säkerhet och cloud

Telefon 070-966 69 97
E-post juha.jurvanen@jufcorp.com

Sammanfattning

Second line drift av Citrx Server i VMware med kluster för ALMI Företagspartner
Uppdraget bestod i att vara behjälplig med driften av ALMIs virtuella miljöer i klustrad VMWare ESX miljö med Citrix , föreslå förbättringar och vara ansvarig för backupdriften och vissa säkerhetsfrågor.

I arbetsuppgiterna ingick även användarhantering, nya installationer av programvaror, uppdateringar, felsökning och server´hantering med nya installaioner av förekommande program som Microsoft SQL Server, Exchange Server och klientapplikationer som Office o.s.v

Som teknikchefRed Coud IT har jag varit den som varit IT arkitekt och designat, driftat och skött second line support och helpdesk för molntjänsten rCloud Office baserad på Microsoft Windows 2008 R2 Server Remote Desktop Services.
Under en längre period var jag även konsultchef och IT Chef med ansvar för 6 konsulter och tekniker.
Under tiden Red Coud IT erbjöd konsulting kan t.ex. företag som Loomis och Boliden nämnas där jag hjälpte till med frågor kring backuphantering och upphandlingar. Red Cloud har dock renodlats till en molnleverantör och konsulting kring drift och säkerhetsfrågor kommer återgå till egen regi i JufCorp. Jag är dock fortfarande second line drift av molntjänsterna och delägare i företaget,

Behjäplig vid installation., design och implementation av Citrix lösning för Ticket (som anställd på Enator)

Behjäplig vid installation., design och implementation av Windows Serevr miljö för Nyman & Shultz (som anställd på Enator)

Jag har längst arbetat som backup / restore expert och specialst på SunGard , tidigare BackupCentraleni 8 år inom många olika server-plattformar (Windows, NetWare, Solaris, Linux) och senare i mitt eget fristående bolag JufCorp.

Från januari 2010 har min tidigare verksamhet och engagemang varit inom Red Cloud IT där jag också är fortsatt delägare och sk cloud arkitekt och CTO/CIO och konsultchef.

Från sommaren 2012 har dock Red Cloud IT renodlat sin verksamhet till molntjänster och därför har konsulting successivt återtagits till JufCorp.

Senior IT konsult

Jag har 16 års erfarenhet som IT konsult varav karriären började på Enator 1996 som PC/LAN konsult på NetWare och Windows samt Citrix med drift hos kunder som Nyman & Schutz, Ticket, American Express , Norrköpings kommun och Rikspolisstyresen. Bland system kan nämnas Lotus Domino, Exchange, Microsoft SQL Server, MySQL och de flesta vanliga förekommande uppgifter vad gäller serverdrift och övervakning av servrar.

Jag har under de många åren inom IT branschen arbetat med tjänster inom IT-Support, nätverksteknik, administration, allehanda säkerhetsfrågor, helpdesk, projektledning med mera. Jag har även varit arbetsledare och teamleader i projekt, agerat säkerhetsspecialist, LAN / WAN tekniker,systemtestare och IT arkitekt och IT strateg av stora och små IT miljöer samt IT Chef och konsultchef.

Om Juha Jurvanen

På fritiden umgås jag med min sambo och våra 4 katter och går gärna på konserter eller bio då musik och film är ett stort intresse. Jag har ett stort intresse för IT så mycket av min tid går til och jag skriver även i några bloggar b.la. http://jufflan.syspeace.com samt http://syspeace.wordpress.com

Som person är jag lugn, positiv, trevlig och mycket målinriktad och alltid professionell i mitt agerande med kunder eller era externa kontakter och brinner för att genomföra projekt och installationer på bästa möjliga sätt för attt nå önskade mål och lösningar och alltid inom överenskommen tidsram.

Anställningar och egna företag

Fristående konsult inom backup, IT drift, IT säkerhet och molntjänster JufCorp

2007-04-15 –
Som fristående egen konsult har jag jobbat med drift av mijöer som t.ex. på ALMI Företagspartner med VMWare och Citrix där jag driftade och hjälpte till med säkerhetsfrågor och backuplösningar. Vid behov hjälpte jag även till som projektledare för kommunkationsprojekt och brandväggsfrågor.
Jag har hjälpt kunder med att t.ex. skriva återstartsplaner s.k. DRP / BCP och varit rådgivande i olika säkerhetsfrågor men även varit behjälplig med praktiska frågor som uppgraderingar och migreringar av Active Directory och Lotus Domino till Microsoft Exchange, Sharepoint installationer, övervakning o.s.v. Bland andra kunder kan t.ex. Vårdförbundet, Heidrick & Struggles, 7e AP Fonden nämnas.

Jag blir ofta anlitad som fristående specialist vid olika frågeställningar vid implementationer och integrationer mellan system och olika säkerhetsaspekter som driftssäkerhet, backupsäkerhet o.s.v.
Bland övriga applikationer jag driftat och arbetat med kan nämnas Microsoft SQL Server, MySQL, Microsoft Exchange Server, IIS Server, Visma, Pyramid, Scala o.s.v

Teknik och konsultchef CTO/CIO och delägare och upphovsman Red Cloud IT

2010-01-01-
Som teknikchef på Red Coud IT har jag varit den som varit IT arkitekt och designat, driftat och skött second line support och helpdesk för molntjänsten rCloud Office baserad på Microsoft Windows 2008 R2 Server.
Under en längre period var jag även konsultchef/IT Chef med ansvar för 6 konsulter och tekniker. Under tiden Red Coud IT erbjöd konsulting kan t.ex. företag som Loomis och Boliden nämnas där jag hjälpte till med frågor kring backuphantering och upphandlingar. Red Cloud har dock renodlats till en molnleverantör och konsulting kring drift och säkerhetsfrågor kommer återgå till egen regi. Jag är dock fortfarande second line drift av molntjänsterna och är forfarande delägare i företaget.

Initiativtagare och upphovsman till Syspeace

2011-11-01-
Mitt intresse för säkerhetsfrågor och automatisering ledde till projektet Syspeace där jag varit initiativtagare för att utveckla en programvara för automatisk intrångshantering på Windows server miljöer.
Bakgrunden var att jag insåg ett behov baserat på alt jobb jag gjort i större datamiljöer och datacenters där det här alltid varit ett svårt problem att lösa på just den plattformen.

Som olika sätt att marknadsföra det skriver jag t.ex. i bloggen http://syspeace.wordpress.com och http://jufflan.wordpress.com .
Den senare är bredare och handlar om servermiljöer i datacenters o.s.v. Min nuvarande roll i Syspeace kan närmast beskrivas som produktansvarig och idéspruta samt testare

DR Specialist och drift online backuper SunGard

1998-12-01 – 2006-11-01
På SunGard (tidigare BackupCentralen) var jag anstäld som DR tekniker och gjorde årligen hundratals restoretester Windows, Netware, Linux och Solaris. Bland uppgifterna ingck allt från praktisk restore till att förbereda mijöer , planera IP nät och migreringar o.s.v. I jobbet ingick även beredskap för katrastrofhantering av kunders miljöer.Andra arbetsuppgifter var design och drift och presales av online backuptjänsten InfoStage/VytalVault samt konsulting kring olika backupfrågor. På SunGard var kundbasen mycket varierad och det främsta arbetet bestod i just validerng av backuper och hjälpa kunder med sina DRP/BCP planeringar.

IT konsult PC LAN/WAN Enator

1996-02 -01-1998-12-01
På Enator jobbade jag som konsult med drift och suport av servermijöer på b.a. Novell NetWare, Microsoft Windows och Citrix och oika serverapplikationer som t.ex. Lotus Notes / Domino.
Bland kunder och uppdrag kan t.ex. Nyman & Schultz, American Express och Ticket nämnas där program som Amadeus och SMART användes

Jag är van att arbeta i stora servermiljöer och stora datacenters men rör mig lika gärna i mindre miljöer och tätare med kunden. Min långa, och framförallt, breda erfarenhet gör det lätt för mig att sätta mig in i olika typer av lösningar och snabbt kunna hjälpa kunden med vad som dyker upp.

Jag har ofta idéer på automatiseringar och förebýggande arbeten med en god känsla för helheten för att säkerställa en god IT drift och är lyhörd för kundens behov och önskemål

Några projekt och uppdrag från både JufCorp och Red Cloud IT

Syspeace (http://www.syspeace.com)
Att utveckla och skapa en enkel och fungerande intrångshanterare för Windows servrar.
Idén och konceptet är mitt från början och inom projektet har jag agerat testare, projtktledare och kravställare. Syspeace stöder Windows 2003 , 2008, 2008 R2 och är nu lanserad publikt och arbete pågår med stöd för Windows 2012 Server.

IT arkitekt för molntjänsterna på Red Cloud IT
Uppdraget bestod i att designa och implementera en hållbar och kostnadseffektiv för drift av moolntjänster till externa kunder Miljön byggdes av Windows 2008 R2 server där alla aspeketer av byggandet sköttes av mig,. Design av nät, val av hall, brandväggs konfigurationer, uppsättning av servrar o.s.v. rCloud Office lanserades redan 2009.

Konsultchef och driftschef på Red Cloud IT
I egenskap av delägare har jag även haft roillen som konsultchef med chefsansvar för 6 tekniker och utvecklare.

Oberoende konsult vid hjälp av upphandling av backupsystem för Boliden
I uppdraget ingick att granska anbud och tekniska lösningar för Boliden

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

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

Effektivisering av backupmiljö på Loomis AB

Effektivisering och genomgång av backupmijö på Utbildningsradion (UR)

Jag konsultar som second line i allehanda serverfrågor hos t.ex D&E Trading AB

Second line drift av VMware med kluster för ALMI Företagspartner
Uppdraget bestod i att vara behjälplig med driften av ALMIs virtuella miljöer i clustrad VMWare ESX miljö med Citrix , föreslå förbättringar och vara ansvarig för backupdriften

Skapa DR tjänst för Windows servrar
Under min anställning på SunGard uyevklade och skapade jag metodiken för att hantera återställning av komplexa Windows miljöer.

Planeing, uppgradering och implementation av Active Directory 2000 till Windows 2008 R2 för kund

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å Vårdförbundet.
Uppdraget bestod i att hjälpa till med planering, vara behjälplig vid själva testen och utvärderingen och föreslå förbättringar för DR scenarion.

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.

Varirt delaktig i design och implementation av serverpark och klienthantering för resebyrå utspridd över landet

Några utbildningar och kurser

Citrix Administration
Nätverksarkitekt/tekniker
Cisco router installation & administration
Solaris Administration 1 & 2
MIcrosoft SMS Server
Novell System Administrator (CNA)
Etisk hacking och säkerhet
EVault InfoStage Advanced
TCP/IP Networking
Novell Brainshare
Microsoft Teched

Ett axplock av program jag jobbat med

Microsoft Office 4.3 – Microsoft Office 2010
I princip samtliga backupprogramvaror på marknaden
Lotus Notes/ Microsoft Exchange
MS SQL Server 6.5 – 2008 R2, Sharepoint
Drift av olika affärssystem som t.ex. Xor, Visma, Pyramid, FLEX, Hogia, Scala o.s.v.

Serveroperativ och olika system

Microsoft Windows NT 3.51 Server – Microsoft Windows Server 2008 R2
Citrix WinFrame – MetaFrame
Micorsoft Exchange 5.5/2000/2003/2007/2010
Microsoft SMS/SCMM Server
Microsoft Active Directory
Novell NetWare 3.x – 6.5 och Novell produkter somNDS, GroupWise, NAL, Bordermanager Server virtualiseringar som VMWare 3 – VMWare 5 och ESXi, Hyper-V och XEN Server
Linux (t.ex. Red Hat, Ubuntu o.s.v)
Lotus Notes Domino Server 3 – Lotus Domino Serve 8
Backupprogram som t.ex. EVault InfoStage Leagto NetWorker Symantec BackupExec, IBM Tivoli, CA ArcServe/BrighStor
Micosoft SharePoint
Microsoft WSUS och olika automatiserade lösningar för uppdateringar
Brandväggar somt.ex Mcrosoft ISA/TNG, SmoothWall, IPCop, RouterBoard, Clavister o.s.v Diverse antiviruslösningar (F Secure, McAfee, Trend t.ex. ) och
Applikationsdistribution (NAL, SMS, AD MSI t.ex.)

Nätverk

TCP/IP/ IPX/SPXP / IGRP / eIGRP
Ethernet / Token Ring / LAN/WAN / WINS / DNS / SNMP
Planering LAN / WAN, installation, administration, felsökning
ADSL/ISDN Modem och oika uppkopplingsösningar, Installation och konfiguration och felsökning
Switch (3COM, HP, Cisco), Installation och konfiguration och övervakning.
Uppsättning brandväggar installation, administration
Övervakning, inventering. Installation och konfiguration
Trådlösa nätverk, WiFi och säkerhet WPA, WPA2, installation och konfiguration
Avancerad felösökning av system och funktioner i LAN / WAN eller server miljö

Klientoperativ

Microsoft Windows 3.11 – Windows 8
Novel Netware 3.2-6.5
Linux (diverse)
BeOS
OpenSolaris
SUN Solaris

Remote session was disconnected because there are no Remote Desktop client access licenses available for this computer. Please contact the server administrator

Remote session was disconnected because there are no Remote Desktop client access licenses available for this computer. Please contact the server administrator

A weird thing happened today when I was reconfiguring the backups for a bunchs of Windows 2008 R2 servers to get better logging and notifications emaied to me.

One of the servers, all of a sudden really, just started telling me that I coudn’t connect to because of the error message above.
I tried connecting from several servers and clients , Windows 2008 R2 servers, Windows 2008 Servers but I kept getting that message ?

When connecting from a Windows XP , it all worked fine ?

Well, Google is your friend. I found this :

RDP Fix: No Remote Desktop Client Access Licenses Available

Solution : Delete HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSLicensing
on the server/client your are trying to connect from.

(trhe entire key, don’t worry, it will be recreated automatically )

I have absolutely no idea what happened and why but deleting that registry key sorted it out.

A small update. As a first step, please verify that you do indeed have a terminal server licensing server correctly configured …In what I wrote above, the licensing server was up & running and worked for other TS servers so I knew for a fact that it wasn’t the problem.

Juha Jurvanen
Senior IT conusltant in backup, IT securiy, server operations and cloud

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

Hur ser era backuper och återstartsplaner ut ? Disaster Recovery Planning på svenska ..

Juha Jurvanen - senior IT konsult inom backup, IT säkerhet, server drift och molntjänster

Juha Jurvanen

Efter 16 år som IT konsult inom många olika områden är min erfarenhet att backuper oc återstartsplaner fortfarande är en eftersatt fråga. I sak har det inte förändrats mycket , trots molntjänster och förenklade metoder och hur många gånger det än diskuteras på möten blir det ändå eftersatt och uppskjutet.

Ända till den dagen något verkligen händer och de där backuperna behövs.

Backuper är för de flesta ett tråkigt ämne och sällan något som prioriteras, varken av IT avdelningen eller av ledningen men, tyvärr är ändå den krassa verkligheten att backuperna är något av det viktigaste ett företag eller organisation har.

En av de mest grundläggande frågorna varje IT chef och VD måste sälla sig är “Hur länge kan vi klara oss utan vår IT? Timmar ? Dagar ? Månader ?”
Utan den tankegången kommer teknikerna och IT avdelning aldrig att ha ett mål att jobba mot för att skapa en användbar återstartsplan som följer den riktlinjen.

Förarbetet under den normala driften är väldigt viktig att tänka på .
Att inte kontinuerligt övervaka backuperna, testa att de innehåller vad de ska och ha ett öga på eventuella fel kan få väldiga konsekvenser.
Att inte ha planerat igenom hur en stor återställning av hela IT systemet ska gå till i förväg kan leda till en onödigt lång återstartsprocess i sökande efter dokumentation, backuper, hårdvara och kompetenta tekniker.

Att återställa enskilda filer på en server är inte en test av backuperna , det är i bästa fall bara ett test av läsbarheten på backuperna. Ett riktigt återstartstest (Disaster Recovery Test )  ska utgå från scenariot att hela servern eller hela servermiljön helt enkelt inte längre finns att tillgå.

Tekniker som skall återställa ska ha tillgång till backuperna, dokumentationen och hårdvara att återställa till. Det är allt. Ingen att ringa. Ingen att fråga. Syftet skall vara att ha en tillräckligt bra teknisk återstartsplan och kunna följa den så att företaget eller organisationen har tillgång till sina IT system inom den tid som krävs enligt IT policyn och företagets BCP (Business Continuity Plan ) och DRP (Disaster Recovery Plan) .

Här kommer många frågor in per automatik att tänka på.
Alla de här frågorna förutsätter att det redan är konstaterat att det är just backuperna som måste tas till .
För att komma fram till det beslutet krävs också en del planering innan och beslut att fatta baserat på vad som hänt (virusattack, brand, stöld, översvämning, terrorhot o.s.v. ) 

  1. Var finns backuperna?Är de på tape? -Var finns banden? Är de krypterade och vem har lösnorden?
    På disk?  I princip är frågeställningarna de samma som på tape.
    Är det onlinebackuper? – Är de krypterade ? Hur mycket data är det totalt och hur mycket bandbredd har vi att tillgå ? Kommer själva återläsningen av data att ta för lång tid för allt data över den här bandbredden t.ex. 10 Mbits eller 100 Mbits ?
  2. Hur har backuperna tagits ? Vilken backup programvara ha använts och hur får vi tag på den ? Hur återställer man backupservern i t.ex. Legato Networker eller Tivoli TSM för att ens kunna börja återläsa något från backuperna? Hur lång tid tar den initiala återställningen och har vi räknat in den tiden i vår DRP ? För t.ex. Legato kan en sån återställning handla om många, många timmar för man kanske måste scanna igenom varje tape och få in dem i databasen och i TSM är databasen kritisk för att kunna få tillbaka något alls från backuperna.
  3. Hur ser systemdokumentationen ut ?

    Hur var servrarna uppsatta med volymstorlekar, programvaror, operativsystem med service packs o.s.v. ? Många företag missar den här delen i sin återstartplan och det kan leda till ett alldeles onödigt tidsspill under återställningen . Dokumentationen är gammal eller direkt felaktig . Här behövs enkla och automatiserade system som uppdaterar systeminformationen dagligen. Administrativa lösenord behöver också finnas tillgängliga, i Wndows server världen även de lokala administrativa lösenorden och en uppdaterad IP plan kommer behövas.
  4. Till vad ska vi återläsa backuperna?De flesta företag organisationer har inte en dubblerad serverpark som bara står och väntar en katastrof och att veta till vilken hårdvara det faktiskt ska återläsas till är en viktigt fråga att tänka på alltså, hur får vi tag på reserv hårdvara eller ska vi återläsa allt till en virtuell miljö? Hur får vi tag  på en server som kan husera t.ex. 25 servrar med 4 GB RAM vardera minst och 50 GB disk utrymme?
  5. Vart ska vi göra den faktiska återläsningen? Om företaget eller organisationen drabbats av en större olycka kommer det troligen inte att gå att återställa miljön på samma ställe. Det måste finnas en plan för vart både personal och IT personal ska ta vägen för att ens kunna påbörja en återläsning och återuppbyggnad av IT miljön. Oavsett hur så måste förmodligen verksamheten återuppstå förr eller senare.
  6. Vem ska göra vad? Och i vilken ordning?Det här är också hemskt viktiga frågor. Vem eller vilka ska göra det rent praktiska med återläsningen ? Vem ska t.ex. meddela på hemsidan / twitter / press att ni råkat ut för ett haveri och meddela när ni beräknas vara i full drift igen ? På vilka siffror baseras den informationen dvs från tidigare krascher eller tidigare återstartstester eller bara en “allmän känsla” dvs mer eller mindre baserat på gissningar ?

    Finns det redan utsett i vilken ordning olika system och funktioner ska upp och vilka som är mest kritiska och viktigast att få upp först ?

    Om ingen med kunskap om hur miljön var uppbyggd finns tillgänglig, kommer dokumentationen att vara en hjälp eller ett hinder för den externe konsulten s skall hjälpa till ? Att återläsa t.ex. en kraschad Microsoft Exchange Server med tillhörande Active Directory elelr en komlicerad Oracle installation är inte alldeles självförklarande för den som aldrig gjort det innan.

  7. Återställningen i sig – är den permanent eller tillfällig?Om återställningen gått bra så måste man ändå ha klart för sig om det är en tillfällig lösning man återställt sin miljö till och så fort man är i normal drift igen måste man börja planera för återgång till den riktiga miljön igen .

Det här är egentligen bara några av saker som jag vet man måste tänka på för sin verksamhet och framförallt, man måste ta sig tiden att göra det här jobbet , antingen internt eller att anlita en extern konsult som hjälper till med att strukturera upp arbetet och planeringen med nya ögon.

Kommentera gärna eller kom med synpunkter eller kontakta mig för vidare funderingar kring de här frågorna.

Ett möte kostar bara lite tid men kan ge så mycket mer

Juha Jurvanen – Senior IT konsult inom backup, IT säkerhet, servedrift och molntjänster .

Ett inlägg om vad är egentligen VPS, hybridmoln, publika moln, molntjänster o.s.v.

Vad är virtuella servrar, VPS, privata moln, publika moln ?

Av Juha Jurvanen på JufCorp
Senior IT konsult inom backup, IT säkerhet, server drift och cloud

Ibland pågår lite olika debatter kring virtualisering kontra molntjänster eller hybrider. Den här sidan är tänkt att visa på hur saker och ting egentligen hänger ihop och vad de olika sakerna är.

Historiskt med serverdrift

Historiskt har det varit en IT avdelning, egen eller inhyrd, som haft driftat och övervakat ett antal servrar i en hall. Deras uppgift har varit att se till att servrarna fungerar, applikationer och datat går att nå för användarna och att alla loggar läses igenom och hanteras och säkertspatchar läggs på i tid. Oavsett vad du läser fortsättningsvis så är det viktigt att komma ihåg att data lagras alltid någonstans rent fysiskt i någon serverhall. Alltid. Molnet är inget luddigt med data och bitar som flyter omkring i luften bara utan på det ena eller andra sättet hamnar alltid data på någon hårdisk någonstans

Virtualisera servrar

Att virtualisera sina servrar har de senaste åren blivit en stor framgång för många. Kostnadsbesparingarna på hårdvara och el och den något enklare administrationen är en tilltalande effekt. Möjligheterna till avancerade klustrade lösningar för ökad redundans och tillgänglighet är också intressanta möjligheter, Många företag virtualiserar sina servrar och fortsätter administrerar dem som förut, dvs man kollar loggar, hanterar säkerhetsuppdateringar, granska intrångsförsök, antivirus, lägger till program och funktioner vid behov. Det man i princip har vunnit är alltså att man behöver ha mindre hårdvara att hålla reda. En del av de programvaror som finns är väldigt väl testade och kan visserligen kosta ganska mycket i licenser men besparingen på hårdvarusidan kan ändå göra det lönsamt. Man har alltså också kvar sin vanliga serveradministration och ofta har användarna sina applikationer installerade lokalt på sin PC (vilket ju är den vanligste plattformen).

Virtualisera program

Nästa steg är att titta på att virtualisera applikationerna med olika tekniker dvs istället för att klienterna har programmen installerad så streameas / publiceras de ut till klienterna och alla använder en centralt installerad kopia. Den här tekniken har verkligen mognat de senaste 3-4 åren är äntligen funktionell för att tillhandahålla det som tidigare kallades ASP. På det här sättet sparar man mycket springande i korrider med CD / DVD skivor för installationer och man kan enkelt uppdatera så att alla har en och samma version av programmen och de är enkelt och snabbt tillgängliga. Antlingen via enkla genvägar eller via t.ex. en webportal. I mångt och mycket är det en återgång till centraliserad IT som kom redan med stordatorerna på 1970-talet.

Extern VPS

För att slippa ha hårdvara överhuvudtaget på serversidan finns nuförtiden också möjligheten att hyra s.k. VPS ( Virtual Private Server). I praktiken är tankesättet det samma som med virtualisering, med den stora skillnaden att de virtuella servrarna ligger i en molntjänst där resurser kan tilldelas dynamiskt och man betalar för den bestyckning man tycker sig behöva. Beroende på leverantör kan servrarna rent fysikt befinna sig varsomhelst i världen vilket vara lite bekymmersamt för vissa företag. Man har oftast också fortfarande kvar administrationen av servern med säkerhetspatchar, granska intrångsförsök o.s.v. Det är sällan en leverantör av VPS tar på sig det ansvaret.Man har alltså bara flyttat ut hårdvara ut det egna företaget vilket naturligtvis är ett steg i rätt riktning även med VPS kan man bygga lösningar med t.ex. virtualiserade/publicerade applikationer. I sak är det bara en server med ett operativ, även om man inte kan ta på den fysiskt i sin egen serverhall.

Hybrid moln

Hybrider handlar om att man tar delar av sin IT miljö och flyttar ut til någon form av molntjänst. Det kan vara t.ex. CRM eller mail eller något annat men man behåller resten av datat i sin egen serverhall som man av olika anledningar inte vill ha utanför företaget. De funktioner som finns i molntjänsten är tillgängliga på samma sätt som de vore installerade lokalt men rent tekniskt ligger de inte lokalt. Vissa applikationer är väldigt svårt att flytta ut på det viset då integrationen till andra program som finns runtomkring är så stark att programmen fungerar dåligt utan allt det kringliggande som behövs.

Privata moln

Ett privat moln betyder i praktiken att man har satt upp ett system för att publicera applikationer från en central punkt till sina användare inom företaget. Ett privat moln kan i sin tur vara byggt på antingen en virtualiserad miljö eller på många enskilda, fysiska servrar.

Publika moln

Ett publikt moln är ett stort, redudant, lastbalanserat system som är uppsatt av en leverantör som gör det tillgängligt för flera olika företag (och ofta privatpersoner) att kunna nyttjas gemensamt och på det sättet delas på de resurser som finns. De flesta leverantörer av publika molntjänster, särskilt vad gäller applikationsutbudet , har ett antal färdiga programpaket de erbjuder och det finns ingen möjlighet att t.ex. flytta ut några av sina egna applikationer till dem eller göra förändringar i utbudet I sånt fall är man hänvisad till att antingen bygga ett eget moln eller hyra in sig på VPSer och drifta dem själv.

Securing your server environment – part 1 – Physical environment

Securing your server environment – part 1 – Physical environment

Juha Jurvanen’s thoughts on server security 
This blog post is intended only as a basic guide to security. It is not intended to be the gospel of security since, 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. Absolute computer security is a myth. That said, system administrators can still do a lot to make more difficult to access data and prevent DDOS attacks on their system
Let’s start off with physical aspects .
Where is your server actually located and who has physical access to it? 
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 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 almost at all times carry with me some USB stick that I 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.
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, switch disks on RAID systems or just put small holes in all the networks 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.

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.
  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. 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. 
  2. 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. 
  3. 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. 
  4. 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 Microsoftfor 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 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 ), 
  9. 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, treats the secondary DR location as mission critical data. 
  10. Once again, do not underestimate the powers of social engineering. Although it’s not hacking in the usual sense, it’s merely  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 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 “Juffe” Jurvanen
Senior consultant in backup, IT security, server operations and cloud

Mail från Google till JufCorp ??

Jag fick det här oväntade mailet idag
.
Jag har ett litet företag som sysslar med backuper, disaster recovery planer,  IT säkerhet , server drift och cloud konsulting. Jag har aldrig använt Google Adwords tidigare mer än nu när jag fick en sån där gratis testa på sak så jag kan inte riktigt se varför JufCorp skulle vara en “utvald kund”?

Jag har tidigare alltid sagt att ringa Google är som att ringa Gud .. så vad betyder det här ? Är det ens på riktigt eller är det en scam? För en gång skulle är jag faktiskt osäker..
Ibland är det bra att vara paranoid, ibland inte och nu kan jag inte avgöra vilket som är vilket den här gången.
För att citera en tidigare kollega “Bara för att du är paranoid betyder det inte att ingen är ute efter dig” ..

Juha Jurvanen
Senior IT konsult inom backup, serverdrift, IT säkerhet och cloud

Mailet nedan:

Hej,

 

Jag heter Maria och jag skriver från AdWords Energize teamet här på Google.

 

Vårt team specialiserar sig i erbjuda kostnadsfria och skräddarsydda konsultationer till utvalda kunder. Jag har tittat på ditt konto ********** och ser flera möjligheter för förbättringar så att du kan få ut mer ut av din budget och därför vill jag erbjuda dig vår kostnadsfria Energize konsultation och support de nästkommande 28 dagarna.

 

Du kan ringa oss på 0200 125 776, måndag till fredag mellan 9 – 18. När du når växeln så måste du slå in ditt kontonummer ******** för att komma vidare. Vi ber dig även att vara inloggad på ditt AdWordskonto under samtalets gång. Vi erbjuder kundstöd på svenska men det kan hända att du får tala med en engelsktalande representant om ingen svensktalande finns tillgänglig.

 

 

Hur kan du dra nytta av detta? Vi kan visa dig hur du förbättrar din avkastning, till exempel genom att:

 

– Få fler relevanta kunder att besöka din webbsida, inom din existerande budget

– Minska dina utgifter på onödiga klick som inte ger försäljningsresultat

– Spåra din avkastning på Adwords-utgifter

 

Vi kan även hjälpa dig med andra vanliga frågor som gäller exempelvis betalningar eller tekniska frågor.

 

Vi ser fram emot att höra från dig och kom ihåg – denna kostnadsfria tjänst erbjuds endast till utvalda kunder och utgår om 28 dagar så ring snart!

 

Med vänliga hälsningar,

 

Maria

Google AdWords Energize teamet

 

 

P.S. Du kan inte svara detta e-postmeddelande men om du vill kontakta oss via e-post, vänligen fyll i vårt online formulär: http://www.google.com/appserve/mkt/********** – notera att inloggning krävs.

 

 

 

 

 

Telefonsupport är tillgänglig mellan 10.00 och 14.00. Erbjudandet är begränsat till annonsörer i Sverige. Support är bara tillgänglig på svenska.

 

© 2012 Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland.

 

Det här e-postmeddelandet skickades till *******@jufcorp.com eftersom du har angett att du vill få förslag på hur du kan öka effektiviteten för ditt AdWords-konto. Om du inte vill ha sådana e-postmeddelanden i fortsättningen avanmäler du dig här: http://www.google.com/appserve/mkt/optout/******** Du kan också ändra meddelandeinställningarna i ditt konto genom att logga in på https://adwords.google.com/select/EditCommunicationsPreferences