webinar : comment amener rpsi et rpca vers une situation coopérative ?

CONTINUITÉ MÉTIER ET SECOURS INFORMATIQUE

Convergences et Divergences

Webinar – 5 février 2015

Dominique Nadjar & David Abgrall Consultant manager PCA - Hapsis

Pour plus d’informations :

www.hapsis.fr

Cabinet de conseil indépendant créé en 2002 par

des professionnels de la sécurité informatique.

QUI SOMMES-NOUS ?

La mission de Hapsis a pour objectifs d’identifier, de

quantifier et de gérer des risques par la mise en

œuvre de processus de sécurité dont l’efficacité est

renforcée par des compétences et des

comportements adéquats. La diversité de nos

compétences permet de couvrir un large spectre des

besoins des clients.

© Copyright Hapsis 2015. Tous droits réservés

QU

I SO

MM

ES-N

OU

S ?

1

http://www.hapsis.fr/


QU

I SO

MM

ES-N

OU

S ?

LES CHIFFRES CLES :

2


Introduction & Définitions

Inventaire des souffrances

Recovery Time Objective

Tests et Exercices

Facteurs de complexité

Conclusion

AU SOMMAIRE :

3

SOM

MA

IRE





Tests et Exercices


Conclusion

4

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


INTRODUCTION

En fonction de l’organisation de la structure, la responsabilité du PCA et celle du PSI peuvent être dissociées. Si le Plan de Secours Informatique est logiquement pris en charge par la DSI, la responsabilité du secours métier (hors ressources DSI) est souvent localisé dans une entité fonctionnelle distincte. Dans ce cas précis le développement d’un partenariat efficace PCA/PSI peut être difficile et remettre en cause l’atteinte des trois principaux objectifs de ce partenariat : Contribuer à l’alignement du niveau de secours du Système d’Information sur les

exigences des métiers

Définir et mettre en œuvre des solutions techniques qui supportent la reprise des activités

Obtenir une meilleure visibilité sur le niveau de secours du SI et des applications

Problématique : Comment amener RPSI et RPCA à coopérer efficacement ?

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES

5


DÉFINITIONS : PCA vs PSI

Plan de Continuité des Activités (PCA) / Business Continuity Plan (BCP)

Le Plan de Secours Informatique permet de couvrir un sinistre sur un site informatique via la mise en place d’une architecture spécifique et de procédures techniques.

Org

anis

atio

n d

e c

rise

Datacenter Site utilisateurs

Datacenter Site utilisateurs

PCA PRU

PSI DRP PRA PCIT

Le Plan de Repli Utilisateur permet de couvrir un sinistre sur un site utilisateurs via la mise en place de stratégies de repli et des procédures fonctionnelles.

• Le PCA met le processus métier au cœur de la solution et s’assure de la mise à jour et du caractère opérationnel du PSI.

• Le PSI a pour objectif de maintenir la disponibilité et l’accessibilité du système d’information en cas de sinistre.

6

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES





Tests et Exercices


Conclusion

7

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


INVENTAIRE DES SOUFFRANCES

• Remise en cause des RTO recensés dans le cadre du Business Impact Analysis par la

DSI • Peu de visibilité sur le niveau de secours du SI et de ses applications • Absence de référentiel applicatif • Incompréhension/questionnement sur les RTO mesurés par la DSI (Tests unitaires

vs Tests Globaux) • Peu de solutions techniques proposées dans le catalogue de la DSI

• Surévaluation des RTOs exprimés par les métiers (Syndrome de la liste au Père

Noël) • Apparition ponctuelle d’applications inconnues (suite à une mise à jour du BIA) • Demandes récurrentes de mise en œuvre de solutions techniques pour le secours

utilisateurs (Accès à distance, VDI, création de Masters…) • Difficulté pour tester le secours d’applications mutualisées sur un même socle

technique avec des responsables métiers différents

Responsable PCA

Responsable PSI

• Manque de rigueur / refus de coopérer • Rétention d’information • Retard technologique / Innovation faible

SA PERCEPTION DU PSI

SA PERCEPTION DU PCA

• Chronophage • Utilité réduite • Connaissance technique faible

8

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES

© Copyright Hapsis 2015. Tous droits réservés 9

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES




• Parlons-nous le même langage ?

Tests et Exercices


Conclusion


DÉFINITIONS : RTO & RPO

La durée d'interruption maximale admissible constitue le temps maximal acceptable durant lequel un processus métier ou une ressource (généralement informatique) peuvent être interrompus après l’occurrence d’un sinistre entraînant une interruption majeure de service.

RTO (Recovery Time Objective) - DIMA (Durée d’Indisponibilité Maximale Admissible)

La perte de données maximale admissible quantifie les données qu'un système d'information peut être amené à perdre par suite d’un incident. Usuellement, elle exprime une durée entre l’incident provoquant la perte de données et la date la plus récente des données qui seront utilisées en remplacement des données perdues. Cette durée est exprimée généralement en heures ou minutes.

RPO (Recovery Point Objective) - PDMA (Perte de Données Maximale Admissible)

Activation du secours

Reconstruction Synchronisation

DIMA

Sauvegarde Sauvegarde Sauvegarde

PDMA

10

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


RTO EXPRIMÉ

Amnésie (et/ou désintéressement ?) Surévaluation par rapport au besoin

réel Besoin de connaître le niveau de

secours en place

- [PCA] Quelle est votre durée d’interruption maximale admissible pour l’application SOFIX ? - [Métier] Bah je dirais 2 heures… - [PCA] Vous aviez répondu 1 jour l’an dernier… - [Métier] Ah bon ? Qu’est ce que l’on a aujourd’hui?

RPCA & Métiers : Le syndrome de la liste au Père Noel

Rappeler la définition du RTO et les enjeux de cette démarche (Revue du secours en place => coûts à prévoir en cas d’upgrade)

Challenger le RTO avec le niveau de criticité de l’activité ou du processus métier que supporte l’application (Business Impact Analysis)

Problématiques Axes de résolutions

11

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


- [PCA] Après consolidation du BIA, il ressort que les RTO de SOFIX et SUMMOT doivent passer à 2 heures. - [PSI] 2 heures c’est pas possible pour les infrastructures de SOFIX. D’autant plus que lorsque l’application tombe, les métiers/utilisateurs mettent 1 semaine à s’en apercevoir, preuve que ce n’ est pas critique. Et pour SUMMOT, je n’ en ai jamais entendu parler…

RPCA & RPSI : Le Père Noel ne fera pas de cadeaux ce coup ci…

Remise en cause brutale de l’expression de besoin métier

BIA truffé d’applications inconnues de la DSI

Obtenir des preuves que le métier ne supporte plus cette situation (Mails incidents, impacts Financier ou autre afin de forcer le dialogue et revoir l’architecture de l’application)

Exiger la mise en œuvre d’un référentiel applicatif à jour et maintenu par la DSI qui spécifie le RTO sur lequel la DSI s’engage mais aussi le RTO mesuré dans le cadre des tests

Nettoyer la liste des applications avant de la présenter au RPSI. Prévoir des ateliers de travail en cas d’absence de référentiel applicatif.

Problématiques Axes de résolutions

RTO EXPRIMÉ

12

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


• Classification Gold, Silver,

Bronze, ou P1, P2, P3, ou Vitale, Critique,…)

• Classification héritée de l’infrastructure qui héberge l’application

• Engagement de la DSI sur un RTO pour chaque niveau

• RTO « contractuel » dont le respect ne sera prouvé que grâce aux tests

RTO RÉEL OU MESURÉ

« La DSI m’assure que le RTO actuel de SOFIX est de 6 heures. Que dois-je réellement comprendre? »

RTO THEORIQUE

Niveau de service ou de classification de criticité

de l’application

RTO MESURE

Résultat de tests effectués par la DSI

RTO « Sorti du Chapeau »

Indisponible ou non mesuré

• Mesuré dans le cadre d’un

test applicatif unitaire

OU • Mesuré dans le cadre d’un

exercice de simulation de perte de datacenter

1 2 3

13

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


IMPACT DE LA MUTUALISATION DES INFRASTRUCTURES INFORMATIQUES

• Application utilisée par plusieurs

métiers distincts ayant des besoins en secours différents.

• L’application a été conçue en premier lieu pour des besoins « SILVER »

Métiers Applications Infrastructures

RTO GOLD

RTO SILVER

RTO GOLD

RTO SILVER

1

2

Cas n° 1

• Plusieurs applications hébergées

sur un même socle technique et utilisées par des métiers distincts ayant des besoins en secours différents.

Cas n° 2

14

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES Introduction & Définitions



Tests et Exercices

• Rappel des contributions


Conclusion


TESTS & EXERCICES

Tests de repli

utilisateur

Tests d’accès à distance

Tests Unitaires

Tests DRP Globaux

Seco

urs

Mét

ier

Seco

urs

Info

rmat

iqu

e

• Mise à jour et déploiement de masters/image système et validation des zonings

• Déploiement d’applications spécifiques à la demande des métiers

• Fournitures/déploiement d’équipements réseau ou autre en cas de repli interne

• Support utilisateur

• Tests de charge / nombres de connexions simultanées possibles

• Ouvertures de flux • Support utilisateur

La DSI intervient en

tant que contributeur du

PCA

Le RPCA intervient en

tant contributeur

• Mobilisation des métiers pour réaliser les tests de validation fonctionnels de l’application en environnement de secours et lors du retour en production

• Remontée des résultats de tests auprès des métiers avec mise en évidence des RTOs non validés

16

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES




Tests et Exercices


• Sinon c’est trop simple

Conclusion


REGLEMENTATION

Un contexte règlementaire flou et souvent méconnu des équipes informatiques

« ensemble de mesures visant à assurer, selon divers scénarios de crises, y compris face à des chocs extrêmes, le maintien, le cas échéant de façon temporaire selon un mode dégradé, des prestations de services essentielles de l'entreprise puis la reprise planifiée des activités ».

Dans le cas d’une sous-traitance (infogérance…) cette méconnaissance renforcée par : La multiplicité des clients La multiplicité des environnements règlementaires Méconnaissance des choix d’architectures du SI lié A la complexité du SI A la multiplicité des plateformes

Parmi les éléments qui conditionnent la définition d’un schéma directeur IT, les problématiques de règlementation liées à la continuité d’activité ne sont pas ou peu prises en compte.

Extrait du règlement CRBF 97-02

18

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


FACTEURS DE COMPLEXITE ET IRRITANTS

Non respect des normes et standards internes

• Utilisation d’applications développées en interne par les métiers et hébergées sur un NAS • Stockage de données sensibles sur un poste utilisateur en local plutôt que sur le réseau comme

préconisé

Organisation et structure de l’entreprise

Business Unit 1

Business Unit 3

DSI (Infrastructures)

DSI 1 (Applications)

Business Unit 2

DSI 2 (Applications)

• Echanges plus complexes lorsque la DSI est fractionnée (entités distinctes pour la gestion des applications et des infras) avec des interlocuteurs intermédiaires.

• Difficulté pour la DSI d’organiser un test d’applications mutualisées sur un même socle technique avec des responsables métier différents (parfois même issus de départements différents).

Applications complexes ou soumises à de nombreuses migration/refonte

• Plusieurs noms utilisés et désignant une seule et même application • Architecture applicative complexe (nombreux composants, plusieurs instances, modules derrière

une même application)

19

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES




Tests et Exercices


Conclusion


CONCLUSION GUIDE POUR DEVELOPPER UN PARTENARIAT EFFICACE

Responsable PCA Responsable PSI

• Exiger la mise en œuvre d’un référentiel applicatif complet et à jour (et prendre part aux réflexions et réunions projets associées)

• Partager les principes d’architecture et de résilience du SI et les contraintes associées (rôle d’éducateur)

• Partager les résultats des tests unitaires/globaux en précisant la « nature » des RPOs et si besoin les composants applicatifs non testés

• Utiliser les besoins du PCA métiers pour établir un schéma directeur du secours du SI

• Disposer d’une « Charte Continuité d’Activité » formalisant les principes directeurs en matière de continuité et les engagements réciproques

• Etablir une instance bipartite PCA/PSI pour fluidifier les échanges (via des réunion mensuelles) et établir un dialogue constant, ne se limitant pas à la transmission d’une liste de besoins « bruts »

• Partager un référentiel applicatif commun et engager un processus d’amélioration continue pour l’harmonisation des dénominations

• Clarifier les questions budgétaires et de refacturation

• Argumenter/Justifier les besoins métiers (impacts financiers, nouveaux objectifs stratégiques ou autres…)

• Veiller à fournir des documents propres à la DSI (listes d’applications sans doublons avec informations techniques et mode d’accès pour nouvelle application détectée)

• Profiter des campagnes BIA pour sensibiliser les métiers aux bonnes pratiques (stockage de données et hébergement d’applications, mise à jour des référentiels)

• Partager les exigences, contraintes et insatisfactions métiers liées à l’usage du SI (ex: problèmes de performance)

• Maintenir un Gap Analysis entre besoins exprimés et situation réelle

ET SURTOUT :

21

FAC

TEU

RS

DE

CO

MP

LEX

ITE

CO

NC

LUSI

ON

IN

TRO

DU

CTI

ON

R

ECO

VER

Y TI

ME

OB

JEC

TIV

E TE

STS

ET

EXER

CIC

ES

INV

ENTA

IRE

DES

SO

UFF

RA

NC

ES


MERCI !

POUR ALLER PLUS LOIN …

Contactez-nous :

David Abgrall : [email protected] Dominique Nadjar : [email protected]

Tel : 01 53 16 30 60

www.hapsis.fr

CO

NTA

CT

22

DES QUESTIONS ?

mailto:[email protected]

mailto:[email protected]

http://www.hapsis.fr/