SECTION V: SYSTEM ADMINISTRATION

Transcription

1 SECTION V: SYSTEM ADMINISTRATION ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 1 of 30

2 DOCMENT HISTORY Document History Edi. Rev. Date Description Action (*) Sections /08/2004 Creation I /08/2004 pdated after internal review /09/2004 pdated after feedback DG TAXD /10/2004 pdated after SEVE quality review, SfR /11/2004 SfR visibility check point /01/2005 pdated after SEVE quality review, SfR /03/2005 pdated for SfA /04/2005 SfA v 1.b /04/2005 SfA verification /03/2006 pdated for internal review /03/2006 SfR /05/2006 SfA /08/2006 Corrective Maintenance following DG TAXD request with MS comments received on 4/07/ /03/2007 Internal review 2 02a 19/04/2007 pdated for internal review /04/2007 SfR /06/2007 SfA /09/2007 Incorporating FESS v2.10 Workshop Decisions (ECWP 31). Submitted for review to DG TAXD /09/2007 Incorporating DG TAXD comments. Submitted for acceptance to DG TAXD /10/2007 Implementing verification comments. Re-submitted for acceptance to DG TAXD /10/2007 Submitted for review to DG TAXD /11/2007 Submitted for acceptance to DG TAXD /11/2007 Submitted for publication to DG TAXD /03/2008 Implementing ECWP#35 WDs and FESS Known Issues version Submitted for review to DG TAXD /04/2008 Submitted for acceptance to DG TAXD /04/2008 Re-submitted for acceptance to DG TAXD. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 2 of 30

3 DOCMENT HISTORY /10/2009 Evolutive Maintenance incorporating RFCs FESS- 001, FESS-002-REV1, FESS-004, FESS-005, FESS-007, FESS-010, FESS-011-REV1, FESS- 013, FESS-015, FESS-016, FESS-017, FESS-018, FESS-020, FESS-022, FESS-023, FESS-024, FESS-026-REV1, FESS-027, FESS-028, FESS- 029, FESS-030, FESS-031, FESS-032-REV1, FESS-033, FESS-034, FESS-035-REV1, FESS- 037-REV1, FESS-040 and FESS-041. Submitted for review to DG TAXD /11/2009 Implementing DG TAXD comments and RFC FESS-014. Submitted for acceptance to DG TAXD /11/2009 Submitted for information to DG TAXD /03/2010 Evolutive Maintenance incorporating RFCs FESS- 006, FESS-008, FESS-009, FESS-012, FESS-019, FESS-021, FESS-025, FESS-036, FESS-038, FESS-039, FESS-042, FESS-044, FESS-045, FESS-046, FESS-047, FESS-048, FESS-049, FESS-052, FESS-053 and FESS-054. Submitted for review to DG TAXD /03/2010 Implementing DG TAXD comments. Submitted for acceptance to DG TAXD /07/2010 Evolutive Maintenance incorporating RFCs FESS- 003-REV2, FESS-050, FESS-051, FESS-055, FESS-056, FESS-060, FESS-061, FESS-062, FESS-063, FESS-064, FESS-065, FESS-066, FESS-067 and FESS-068. Submitted for review to DG TAXD /07/2010 Implementing DG TAXD comments. Submitted for acceptance to DG TAXD /07/2010 Submitted for information to DG TAXD /09/2010 Evolutive Maintenance incorporating RFC FESS Submitted for review to DG TAXD /10/2010 Submitted for acceptance to DG TAXD /12/2010 Evolutive Maintenance incorporating RFCs FESS- 072, FESS-073, FESS-075, FESS-076, FESS-077, FESS-078, FESS-079, FESS-080, FESS-081, FESS-083, and FESS-084. Submitted for review to DG TAXD /01/2011 Implementing DG TAXD comments. Submitted for acceptance to DG TAXD /01/2011 Submitted for information to DG TAXD /02/2011 Removal of implementation of RFC FESS-080. Re-submitted for information to DG TAXD. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 3 of 30

4 DOCMENT HISTORY /01/2012 Evolutive Maintenance incorporating RFCs FESS- 085, FESS-086, FESS-089 and FESS-095. Submitted for review to DG TAXD /01/2012 Submitted for acceptance to DG TAXD /01/2012 Submitted for information to DG TAXD /06/2012 Evolutive Maintenance incorporating RFCs FESS- 057, FESS-071, FESS-074, FESS-087, FESS-088, FESS-090, FESS-091, FESS-092, FESS-093, FESS-094, FESS-096, FESS-097, FESS-099, FESS-100, FESS-101, FESS-102, FESS-103, FESS-104, FESS-105, FESS-106, FESS-107, FESS-108, FESS-110, FESS-111, FESS-112, FESS-113, FESS-114, FESS-116, FESS-117, FESS-118, FESS-122, FESS-123, FESS-124, FESS-125, FESS-126 and FESS-127. Submitted for review to DG TAXD /07/2012 Submitted for acceptance to DG TAXD /07/2012 Submitted for information to DG TAXD /09/2012 Incorporating internal review comments and MS verification comments: pdate of Rule025 (Appendix D) to add the items 37 = Movement verification request reasons and 38 = Movement verification actions ; Implementation of FESS CPs #4 and #8. Submitted for information to DG TAXD /10/2013 Evolutive Maintenance incorporating RFCs FESS- 128, FESS-129, FESS-133, FESS-134, FESS-135, FESS-136, FESS-138 and FESS-139. Submitted for review to DG TAXD /11/2013 Implementing DG TAXD comments. Submitted for acceptance to DG TAXD /08/2014 Evolutive Maintenance incorporating RFCs FESS- 059, FESS-121, FESS-131, FESS-132, FESS-140, FESS-141, FESS-142, FESS-143, FESS-144, FESS-145, FESS-146, FESS-147, FESS-148, FESS-149, FESS-150, FESS-151, FESS-152, FESS-153 and FESS-154. Submitted for review to DG TAXD /09/2014 Submitted for acceptance to DG TAXD /05/2016 Evolutive Maintenance incorporating RFCs FESS- 161, FESS-162, FESS-163, FESS-164, FESS-165, FESS-170, FESS-171, FESS-172, FESS-173, FESS-174, FESS-175, FESS-178 and FESS-180. Submitted for review to DG TAXD /06/2016 Submitted for acceptance to DG TAXD /08/2016 Evolutive Maintenance incorporating RFCs FESS- 199, FESS-203 and FESS-204. Submitted for review to DG TAXD. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 4 of 30

5 DOCMENT HISTORY /08/2016 Submitted for acceptance to DG TAXD /09/2016 Evolutive Maintenance incorporating RFCs FESS- 156, FESS-157, FESS-158, FESS-159, FESS-160, FESS-166, FESS-167, FESS-169, FESS-176, FESS-179, FESS-181, FESS-182, FESS-183, FESS-184, FESS-185, FESS-186, FESS-187, FESS-188, FESS-189, FESS-190, FESS-191, FESS-192, FESS-193, FESS-194, FESS-195, FESS-196, FESS-197, FESS-198. Submitted for review to DG TAXD /09/2106 Submitted for acceptance to DG TAXD /12/2016 Submitted for Information under corrective maintenance to DG TAXD /03/2017 Corrective Maintenance incorporating RFCs FESS- 202, FESS-205, FESS-206, FESS-207, FESS-208, FESS-209. Submitted for Information to DG TAXD. (*) Action: I = Insert, R = Replace, = pdate, D = delete ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 5 of 30

6 TABLE OF CONTENTS Table of contents 1... Introduction System administration use cases Management of user accounts of officials (C0.01) Management of user accounts of economic operators (C0.02) Management of access rights of officials (C0.03) Management of access rights of economic operators (C0.04) Manage unavailability (C0.07) Configuration management and version control (C0.22) Data management (C0.23) Fallback procedures (C0.24) Problem tracking (C0.26) Audit trail (C0.25) Index of EBPs ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 6 of 30

7 TABLE OF FIGRES Table of figures FIGRE 1 PARTICIPANTS OF <C0.01> MANAGEMENT OF SER ACCONTS OF OFFICIALS... 9 FIGRE 2 MANAGEMENT OF SER ACCONTS OF OFFICIALS PROCESS FLOW DIAGRAM FIGRE 3 PARTICIPANTS OF <C0.02> MANAGEMENT OF SER ACCONTS OF ECONOMIC OPERATORS FIGRE 4 MANAGEMENT OF SER ACCONTS OF ECONOMIC OPERATORS PROCESS FLOW DIAGRAM FIGRE 5 PARTICIPANTS OF <C0.03> MANAGEMENT OF ACCESS RIGHTS OF OFFICIALS FIGRE 6 MANAGEMENT OF ACCESS RIGHTS OF OFFICIALS PROCESS FLOW DIAGRAM FIGRE 7 PARTICIPANTS OF <C0.07> MANAGE NAVAILABILITY FIGRE 8 MANAGE NAVAILABILITY PROCESS FLOW DIAGRAM ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 7 of 30

8 INTRODCTION 1 Introduction Section V of the FESS addresses the ancillary tasks in EMCS which can be grouped as following: the first group of functionality covers user account names and access rights: In particular, each Administration, i.e. the Commission and all MSAs, is responsible for the management of user accounts and access rights, each for its own Domain. This responsibility covers not only officials but economic operators as well. Identified users are either persons, services, companies or external organisations; the second group of functionality covers the daily functioning of the system, in particular availability of services and operations statistics; other functions at stake here are dealing with management of configuration, data and exceptions. Chapter 1 is the present Introduction. Chapter 2 contains the System administration use cases covering: the management of user accounts and of access rights; the monitoring of the availability of services; general functions that are required for the support of the EMCS operations. The related paragraphs (from 2.6 to 2.10 included) should be considered as recommendations for the Member States. Chapter 3 is an Index of EBPs (Elementary Business Processes) that compose the functionality; in that Chapter, the se cases and their EBPs are presented in numeric order. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 8 of 30

9 SYSTEM ADMINISTRATION SE CASES 2 System administration use cases 2.1 Management of user accounts of officials (C0.01) Overview A user account is assigned to each official involved in EMCS, either in a MSA or in the Common Domain services. Therefore, the MSAs and the Common Domain manage, each for its Domain, user names and profiles for its officials including assimilated staff such as agents of providers or support agents. The details of processing completely depend on the own rules of the concerned Domain; hence, the following description is provided as a guideline only Participants, motivations and commitments MSA or CS user account manager keeps the register of access authorisations up-to-date C0.01-Management of user accounts of officials Figure 1 Participants of <C0.01> Management of user accounts of officials Main actor the MSA or CS user account manager is responsible for managing officials' account information Other actors none General conditions Trigger new users are to be registered or users are to be removed from the list of authorised use credentials need to be changed; Pre conditions the MSA or CS user account manager is entitled to access the register of access authorisations Post conditions the register of access authorisations is up-to-date ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 9 of 30

10 SYSTEM ADMINISTRATION SE CASES Process flow diagram MSA or CS user account manager E_ user account manager starts accounts maintenance C Manage user accounts of officials R_ user account reference up-to-date Figure 2 Management of user accounts of officials Process flow diagram Major events E_ser account manager starts accounts maintenance Actor: MSA or CS user account manager Location: Premises of the (MSA or Common Domain) central services The decision depends on several criteria: new users are to be registered or users are to be removed from the list of authorised users; credentials need to be changed Minor events None. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 10 of 30

11 SYSTEM ADMINISTRATION SE CASES Processes Manage user accounts of officials Process: C Actor: MSA or CS user account manager Location: Premises of the (MSA or Common Domain) central services Processing mode: p to MSA Conditions: none Description: A user account is assigned to each official involved in EMCS; the Administration must maintain a particular list of authorisations for EMCS, preferably integrated in their general access control lists (SSO system (Single Sign ON system)...). A user name is attached better to a person than to a service. For security reasons, service user accounts potentially shared by several persons are not encouraged. MSAs and the Commission enforce the convenient controls to ensure that the credentials of users are duly protected. For instance: if the credentials are passwords, enforce syntax rules and change rules; if the credentials are an electronic key pair, provide the relevant revocation and renewal support of public key certificates. Recommendations should be made to the administrative units where credentials are shared among several persons, for additional protection measures while remaining able to recover if necessary. Final situation: The register of access authorisations is up-to-date Major result R_user account reference up-to-date Actor: MSA or CS user account manager Location: Premises of the (MSA or Common Domain) central services the register of access authorisations is up-to-date accounts created are available modified credentials take effect Minor results None Messages None. 2.2 Management of user accounts of economic operators (C0.02) Overview At least one user account is assigned to each registered economic operator at his first ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 11 of 30

12 SYSTEM ADMINISTRATION SE CASES registration. In addition, if Member States accept it: each economic operator gets additional user accounts from his Member State (for example to dispatch them to his staff); a tax warehouse gets a user account associated to its Excise number. The user account is communicated to the operator along with his confidential credentials (initial password, electronic key pair or equivalent). These credentials are transferred through a particular secure procedure outside EMCS application. Management of user accounts of economic operators encompasses the revocation of these credentials. The details of processing completely depend on the own rules of the MSA; hence, the following description is provided as a guideline only Participants, motivations and commitments MSA user account manager keeps the register of access authorisations up-to-date C0.02-Management of user accounts of economic operators Figure 3 Participants of <C0.02> Management of user accounts of economic operators Main actor the MSA user accounts manager keeps the economic operators register of access authorisations up-to-date is responsible for managing economic operators account information Other actors none General conditions Trigger new users are to be registered or users are to be removed from the list of authorised use credentials need to be changed Pre conditions the MSA user accounts manager is entitled to access the register of access authorisations Post conditions the register of access authorisations is up-to-date, according to the data managed by ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 12 of 30

13 SYSTEM ADMINISTRATION SE CASES the MSA user accounts manager Process flow diagram MSA user accounts manager E_ user accounts manager starts user accounts maintenance C Manage economic operators user accounts R_ user accounts reference is up-to-date Figure 4 Management of user accounts of economic operators Process flow diagram Major events E_MSA user accounts manager starts user accounts maintenance Actor: MSA user accounts manager Location: MSA's premises The decision depends on the following criteria: new economic operators are registered or economic operators are no longer registered Minor events None. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 13 of 30

14 SYSTEM ADMINISTRATION SE CASES Processes Manage economic operator user accounts Process: C Actor: MSA user accounts manager Location: MSA's premises Processing mode: External Event: the MSA user accounts manager wants to manage economic operators user accounts Conditions: none. Description: A user account name is assigned to each registered economic operator at his first registration. It is communicated to him along with his confidential credentials (initial password, electronic key pair or equivalent). These credentials are transferred through a particular secure procedure outside EMCS application. If the MSA accepts it and a registered economic operator needs it, he requests additional user accounts name(s). There is no difference in access rights of the various user names assigned to the same economic operator (Excise number). If the MSA accepts it, each tax warehouse with a separate Excise number receives one user account name as well. The scope of a user name is limited to the national domain; in particular, it cannot be used for connection to the application of another Member State. MSAs enforce the convenient controls to ensure that the credentials of users are duly protected. This depends on the solution chosen for the Member State. For instance: if the credentials are passwords, enforce syntax rules and change rules; if the credentials are an electronic key pair, provide the relevant revocation and renewal support of public key certificates. Recommendations should be made to the economic operators where credentials are shared among several persons, for additional protection measures while remaining able to recover if necessary. Final situation: the register of access authorisations is up-to-date Major result R_user accounts reference is up-to-date Actor: MSA user accounts manager Location: MSA's premises the register of access authorisations is up-to-date user accounts created are available Minor results None Messages None. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 14 of 30

15 SYSTEM ADMINISTRATION SE CASES 2.3 Management of access rights of officials (C0.03) Overview The MSAs and the Common Domain, each for its Domain, determine how access rights are assigned to officials and which functions they have the right to access. The following proposes the classical user/profile mechanism that is used by NCTS, i.e.: a user accounts manager creates user identities and, where necessary, user credentials; this is the object of use case 0.01; an access control right manager maintains user profiles, i.e. lists of functionalities that will be allowed to users, and registers each user under one or several profiles; this is the object of the present use case. The details of processing completely depend on the own rules of the concerned Domain; hence, the following description is provided as a guideline only Participants, motivations and commitments MSA or CS access control manager keeps the credentials register up-to-date C0.03-Management of access rights of officials Figure 5 Participants of <C0.03> Management of access rights of officials Main actor the MSA or CS access control manager is responsible for managing officials' access rights information Other actors none General conditions Trigger the access rights of already registered users (officials) are to be changed. Pre conditions the MSA or CS access control manager is entitled to access the register of authorisations Post conditions user profiles and assignment of profiles to users are up-to-date ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 15 of 30

16 SYSTEM ADMINISTRATION SE CASES Process flow diagram MSA or CS access control manager E_Access control manager has to manage profiles E_Access control manager has to assign profiles C Manage user profiles of officials C Manage enrolment of officials into profiles R_ser profiles up to date R_Access rights up-to-date Figure 6 Management of access rights of officials Process flow Diagram Major events E_access control manager has to manage profiles Actor: MSA or CS access control manager Location: Premises of the (MSA or Common Domain) central services the functionality has to be re-organised according to a new sharing of tasks. E_access control has to assign profiles Actor: MSA or CS access control manager Location: Premises of the (MSA or Common Domain) central services the access rights of some users (new or not) have to change; new users need to have a user profile assigned Minor events None. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 16 of 30

17 SYSTEM ADMINISTRATION SE CASES Processes Manage user profiles of officials Process: C Actor: MSA or CS access control manager Location: Premises of the (MSA or Common Domain) central services Processing mode: External Conditions: none Description: Each Administration freely determines the definition of user profiles by giving to each profile a name and a list of basic functionality that will be granted to that profile. A profile is composed of a series of basic functions composing the EMCS application; these are not only functions defined in the FESS but complementary functions specific to the concerned Domain as well. A generic list of profiles (FESS functionality only) is proposed in Appendix E. Final situation: the user profiles are up-to-date Manage enrolment of officials into profiles Process: C Actor: MSA or CS access control manager Location: Premises of the (MSA or Common Domain) central services Processing mode: External Conditions: the concerned user identities and user profiles pre-exist Description: Each Administration freely determines which user will belong to which profile. By a combination of several profiles, it is possible to restrict the user rights of each agent to the only functions that he has to perform. Final situation: the access rights register is up-to-date Major results R_ser profiles up to date Actor: MSA or CS access control manager Location: Premises of the (MSA or Common Domain) central services the list of user profiles for officials is up-to-date ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 17 of 30

18 SYSTEM ADMINISTRATION SE CASES R_Access rights up to date Actor: MSA or CS access control manager Location: Premises of the (MSA or Common Domain) central services the appointment of access rights to the authorised officials is up-to-date modified access rights take effect Minor results None Messages None. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 18 of 30

19 SYSTEM ADMINISTRATION SE CASES 2.4 Management of access rights of economic operators (C0.04) Overview A list of user profiles and related functions for economic operators is given in Appendix E. The user profiles of economic operators are pre-built as shown in the second part of Appendix E and depend on a set of attributes of the SEED register (authorised warehouse keeper, registered consignee, temporary registered consignee, registered consignor). The access rights of the operator depend on that profile and only on that profile. So, the only useful link is the relationship between Excise number and account name and each economic operator has access to the exact range of functions (use cases) that corresponds to his profile. There is therefore no specific function for the management of access rights of economic operators. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 19 of 30

20 SYSTEM ADMINISTRATION SE CASES 2.5 Manage unavailability (C0.07) Overview The role of this use case is to enable a MSA to announce the unavailability of application services, so that the other Member States are informed in order to take the necessary actions in their own system to cope with that situation. In such cases, the MSAs may refer to the FRS [R7] that handles business exceptions and related responses. This is achieved by each MSA sending its unavailability to the Common Domain central services (CS/MISE); In turn, the CS/MISE disseminates the information to each MSA. Three possible types of business process unavailability are defined: Scheduled: An unavailability planned in advance by an NEA for any implemented and open business service having specific begin and end date and time; nscheduled: An unplanned unavailability by an NEA for any implemented and open business service having specific begin date and time and optionally end date and time; Non-Implemented: An unavailability that reports the non-implementation of a particular business service Participants, motivations and commitments Common domain central service MSA application Disseminates information Receives and stores information C0.07 manage scheduled unavailability Informs central services on unavailability MSA central services Figure 7 Participants of <C0.07> Manage unavailability Main actor the MSA central services prepares and submits the unavailability for the national application Other actors the Common Domain central service receives and disseminates unavailability. the MSA application receives and stores information on unavailability ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 20 of 30

21 SYSTEM ADMINISTRATION SE CASES General conditions Trigger a MSA wants to inform the other MSA of anticipated unavailability of functional services Pre conditions none Post conditions all MSAs are informed of the unavailability Process flow diagram N_TA_REF MSA central services E_Manage navailability Registration MSA application Common Domain central service C Prepare and send unavailability information (IE770:C_AVA_DAT) (IE770:C_AVA_DAT) C Receive and disseminate unavailability information For each Member State C Receive unavailability information R_MSA informed of unavailability Figure 8 Manage unavailability Process flow diagram ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 21 of 30

22 SYSTEM ADMINISTRATION SE CASES Major event E_Manage navailability Registration Actor: MSA Central Services Location: premises of the MSA navailability of one or several of the MSA business services is registered by the System Administrator (e.g. for system administration or maintenance purposes) Minor events None Processes Prepare and send unavailability information Process: C Actor: MSA Central Services Location: premises of the MSA Central Services Processing mode: Semi-automatic Constraint: none Description: A MSA officer in the Central Services prepares an unavailability message (IE770:C_AVA_DAT) containing: the code of the Member State for which unavailability is announced; the type of unavailability (i.e. scheduled, unscheduled, or non-implemented); the business processes for which an unavailability is registered, among: Support for Functionality (i.e. all FESS business process); Support for EMCS - Central Circuit External Domain Functionality (i.e., all business processes of C2.01, C2.05, C2.06, C2.07, C2.10, C2.12, C2.33, C2.34, C2.36, C2.43, C2.44 and C2.46 of Section II of FESS); Support for EMCS - Central Circuit Common Domain Functionality (i.e. all business processes of Section II of FESS); Support for EMCS - Follow-up and Collaboration Functionality (i.e. all business process of Section IV of FESS); Support for National SEED Functionality (i.e. all business processes of Section III of FESS that are executed by the MSA central services, i.e. national SEED). for each service for which unavailability is registered, begin date and time of unavailability; if the unavailability is scheduled, for each service end date and time of unavailability; if the unavailability is unscheduled or non-implemented, for each service, optionally, end date and time. The officer sends the prepared message (IE770:C_AVA_DAT) to the Common Domain Central Services (CS/MISE). Final situation: The Common Domain is in a position to dispatch unavailability information to all MSAs. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 22 of 30

23 SYSTEM ADMINISTRATION SE CASES Receive and disseminate unavailability information Process: C Actor: Common Domain Central Services Location: CS/MISE Processing mode: Automatic Constraint: none Description: The Common Domain central services application receives the unavailability message (IE770:C_AVA_DAT). It immediately and automatically forwards it to all MSAs (including to the issuing MSA). Final situation: the registered unavailability information has been sent to all MSAs Receive unavailability information Process: C Actor: MSA application Location: premises of each MSA Processing mode: Automatic Constraint: none Description: The MSA application receives the unavailability message (IE770:C_AVA_DAT). Final situation: each MSA is informed of the unavailability of the issuing actor Major result R_MSA informed of unavailability Actor: MSA application Location: premises of each MSA The MSA is in a position to apply the steps it defined for such a case, e.g. configure its own application to queue functional requests or refuse applications for the period of unavailability Minor results None Messages IE770:C_AVA_DAT business process unavailability ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 23 of 30

24 SYSTEM ADMINISTRATION SE CASES 2.6 Configuration management and version control (C0.22) Overview Main functionality for configuration management & version control includes: computer inventory: consists in recording hardware and software configurations of servers and workstations. The inventory should also provide information about the system such as available disk space, processor type, operating system, version; software management: consists in software distribution and software installation; commercial off-the-shelf software (COTS), custom software and even simple files. Software distribution should be based on the inventory information; change control management, including software promotion and version control; dependencies management. This kind of functionality is well met by COTS products. The designer of the future Centrally Developed EMCS Application (CDEA) and of each Nationally Developed EMCS application will have to propose a technical choice to achieve that implementation. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 24 of 30

25 SYSTEM ADMINISTRATION SE CASES 2.7 Data management (C0.23) Overview The main functionality for data management includes: incremental backup; automated backup schedules; backup failure alerts; data restoring; on-line catalogue of archived files and backup versions. This kind of functionality is well met by COTS. The designer of the future Centrally Developed EMCS Application (CDEA) and of each Nationally Developed EMCS application (NDEA) will have to propose a technical choice to achieve that implementation. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 25 of 30

26 SYSTEM ADMINISTRATION SE CASES 2.8 Fallback procedures (C0.24) Overview Different kinds of failures considered hereafter are: the network is faulty or down either in the Common Domain or inside a national administration or between a MSA and an economic operator; the EMCS application of the common domain, of a MSA or of an economic operator is partially or totally down; inconsistencies between the information concerning the same entity kept by different parties (in particular by MSAs); other irrelevant business situations. The technical specification of EMCS will recommend specific solutions to prevent most of the possible cases of failures from arising. It covers such areas as resilience and hardware redundancy to be incorporated in the design of hardware and software of the applications. If however the technical resources break down, the FRS [R7] examines the solution elements that participate in solving issues for each failing use case. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 26 of 30

27 SYSTEM ADMINISTRATION SE CASES 2.9 Problem tracking (C0.26) Overview To assist the help desk in its task, it is helpful to provide the following: a tracking system to record and support the follow up of any detected problem. The main features of that tool should allow for recording: date at which the problem appeared; category of the problem; priority (urgency); who has notified the problem; actions taken; a problem status (e.g. pending ); date at which the action was taken; date by which the user expects information; cross reference to related problems; possible additional comments. the system must present this information in a tabular view, so that the help desk has a picture of the problem tracking history. It must also provide problem report printing and statistics reporting. a communication system with the central help desk to transfer files containing a description of the problem and/or trace files produced by processes. Both systems are well met by COTS. Refer to the forthcoming COS (Central Operations Specification) that handles the problem tracking Audit trail (C0.25) Overview The EMCS includes features for automatic national recording of sensitive data base transactions carried out within the system. Except when triggered by support agents who have special rights, all these transactions are completed by a function of the automated system. The recording of this information must be performed by each application function. These transactions concern the day to day EMCS business (submission of movements, changes, receipt, etc.) and general database management. The system must record, in specific entities, these transactions with the following information: the date; the type of transaction; the entity identifier (List of Offices, movement history); entity keys (ARC, Excise number); change of state associated with related key information (new movement state); a system filled field depending on the concerned entity and transition (if relevant); ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 27 of 30

28 SYSTEM ADMINISTRATION SE CASES identification of the actor who initially submitted the concerned use case (economic operator or official). To analyse that audit trail, Authorised Persons need a system in order to be able to: list all actions in a tabular view with the following columns: action date, action type, entity identifier, identification of the Officer. Additional features include: this list sorted by ascending date and descending date; this list filtered combining the following criteria: date between two given dates, ARC, actor, type of operation; print the current selection. The analysis is performed by a specific application. This kind of functionality is well met by COTS. The designer of the future Centrally Developed EMCS Application (CDEA) and of each Nationally Developed EMCS application will have to propose a technical choice to achieve that implementation. Refer to the forthcoming SESS (Security Excise System Specification) that handles the audit trail. ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 28 of 30

29 INDEX OF EBPS 3 Index of EBPs C0.01 Management of user accounts of officials C Manage user accounts of officials C0.02 Management of user accounts of economic operators C Manage economic operator user accounts C0.03 Management of access rights of officials C Manage user profiles of officials C Manage enrolment of officials into profiles C0.07 Manage unavailability C Prepare and send unavailability information C Receive unavailability information C Receive and disseminate unavailability information ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 29 of 30

30 INDEX OF EBPS [End of section] ECP1-ESS-FESSv SECTION V SYSTEM ADMINISTRATION.doc Page 30 of 30