dokumendiregister.ee
OtsingAsutusedMCP
Otsing›Tervise- ja heaolu infosüsteemide keskus
Muu lepingAvalik

Leping

Tervise- ja heaolu infosüsteemide keskus · 18. jaanuar 2022
Viit
1-4/3011-1
Registreeritud
18. jaanuar 2022
Dokumendi liik
Muu leping
Funktsioon
1 TEHIK tegevuse korraldamine
Sari
1-4 Koostöö, andmetöötluse ja konfidentsiaalsuslepingud
Toimik
1-4/2022
Vastutaja
Marko Valing (TEHIK, Infosüsteemide halduse osakond, Baasinfrastruktuuri talitus)

Failid

  • 📎1-43011-1 18.01.2022 Muu leping.asice1198 KB
  • 📎UATP.PDF4438 KB

Sisu (failidest)

USER ACCEPTANCE TESTING PLAN -- AWARENESS, VISIBILITY & AUTOMATION -- Client: TEHIK Owner: Milan Zapletal, SE (IP Fabric) Date: 11.11.2021 Contents 1. Customer & Document details ................................................................................................................ 3 1.1. Customer Details ..........................................................................................................................................................3 1.2. Document Details.........................................................................................................................................................3 1.3. Project Timeline .............................................................................................................................................................3 1.4. Project scope ...................................................................................................................................................................3 2. TEHIK- Challenges / Acceptance Criteria ..................................................................................... 4 2.1. Challenge #1 – Collected Data accuracy .................................................................................................4 2.1.1. Challenge #1 Detail .......................................................................................................................................................4 2.1.2. Challenge #1 Acceptance criteria ......................................................................................................................4 2.2. Challenge #2 – End-to-End path simulation .........................................................................................4 2.2.1. Challenge #2 Detail .......................................................................................................................................................4 2.2.2. Challenge #2 Acceptance criteria ......................................................................................................................4 2.3. Challenge #3 – Troubleshooting, Root-Cause Analysis ...............................................................4 2.4. Challenge #4 – Audit and compliance .......................................................................................................5 2.4.1. Challenge #4 detail .......................................................................................................................................................5 2.4.2. Challenge #4 Acceptance criteria ......................................................................................................................5 2.5. Challenge #5 – Rouge devices detection ................................................................................................5 2.5.1. Challenge #5 Detail .......................................................................................................................................................5 2.5.2. Challenge #5 Acceptance criteria ..................................................................................................................... 6 3. IP Fabric Solution Overview...................................................................................................................... 6 3.1. Solution architecture & System Requirements................................................................................... 6 3.2. Discovery ready environment – prerequisites - important!!......................................................7 3.3. Automated Discovery ...............................................................................................................................................8 3.4. Discovery Snapshots .................................................................................................................................................8 3.5. Network Site Separation ........................................................................................................................................ 9 3.6. Inventory Tables........................................................................................................................................................... 9 3.7. Technology Tables .................................................................................................................................................... 9 3.8. Topology Diagrams ................................................................................................................................................. 10 3.9. End-to-End Path simulation............................................................................................................................... 11 3.10. Intent-Verification Rules (Network Compliance) ..............................................................................12 3.11. Compliance Dashboard.........................................................................................................................................12 3.12. API Integration...............................................................................................................................................................12 4. Acceptance Criteria Review ................................................................................................................... 14 4.1. Conclusion Summary ............................................................................................................................................. 14 UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 2 1. Customer & Document details The document's primary purpose is to define and organize main client challenges and proof of concept acceptance criteria accomplished with the solution provided by IP Fabric. Duration of the Proof of concept is 2 weeks (10 working days) and is free of charge. 1.1. Customer Details Company Name TEHIK Testing Team Name Network Operations, TEHIK [Tervise ja Heaolu Infosüsteemide Keskus] Testing Engineer #1 Rauno Lehiste Testing Engineer #2 Toomas Nõgisto Signed by Margus Arm 1.2. Document Details Version Date Summary of Changes v 1.0 11.11.2021 Created document for review v 1.1 10.12.2021 Updated document for review v 1.2 05.01.2022 Updated document for review V 1.3 17.01.2022 Added Non-Disclosure Agreement 1.3. Project Timeline Stage Date Notes POC Kick Off 10th Jan 2022 POC Review #1 13th Jan 2022 POC Review #2 19th Jan 2022 POC Closure 24th Jan 2022 1.4. Project scope The plan is to discover entire network, which is 500 network devices. The requirements for the virtual machine (VM) are: Devices CPU RAM HDD (OS + DATA) 500 4 16 GB 90 GB (80G + 10G) UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 3 2. TEHIK- Challenges / Acceptance Criteria The following chapter describes unique challenges and the TEHIK team's acceptance criteria during the Proof of Concept with the IP Fabric platform. 2.1. Challenge #1 – Collected Data accuracy After successful discovery with IP Fabric, the platform creates a mathematical model of the network from state and live network configuration data. The created network model or the snapshot has switching, routing, and security logic built-in permitting advanced visualization and network traffic path simulations, and more. 2.1.1. Challenge #1 Detail Following details about the discovered network should be presented with completeness and accuracy: • Detailed device inventory (HW, SW, part numbers, optical transceivers) • Detailed routing information (routes, VRFs, IP Interfaces) • Detailed VLAN information • VXLAN collection on Juniper devices (Supported in 4.0.2) • Detailed network device table information (LLDP, CDP, MAC, ARP) • Detailed mapping of physical, logical, and virtual end-to-end pathways • The ability to instruct IP Fabric to NOT collect certain types of data o This can be achieved with Discovery Tasks settings • Discover branch offices – There are several devices between branch offices and the DC (IP Fabric will have connectivity to the FW between to collect IP Sec data) 2.1.2.Challenge #1 Acceptance criteria The data provided should be accurate and complete based on the discovered inventory. 2.2. Challenge #2 – End-to-End path simulation To recreate, document or simulate the path simulation is essential for documentation and fast troubleshooting or even network architecture requirements. In IP Fabric one can simulate the End-to-end path, just by entering source and the destination IP address. 2.2.1. Challenge #2 Detail Correct end-to-end path should be simulated over IP Sec tunnels and correct security policies should be evaluated over SRX firewalls. 2.2.2. Challenge #2 Acceptance criteria Correct path simulation will be provided by the IP Fabric platform for supported vendors. 2.3. Challenge #3 – Troubleshooting, Root-Cause Analysis Incident isolation and resolution challenges compounded by difficulty mapping network connectivity and understanding device locations. From the collected dataset of the in-scope devices, IP Fabric will allow the user to simulate a route across the network in visual format. The output will be an end-to-end paths simulation based on the network configuration and state at the time of discovery. UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 4 The IP Fabric platform is not meant to be primarily tool for network operations team (it’s more analytical platform designed for engineering, architecture and automation). The platform doesn’t collect real-time monitoring data (SLAs, real-time interface statistics). However, with detailed information, wholistic network model and the end-to-end path simulation capabilities, it’s the go to platform to support Root-Cause Analysis and troubleshooting scenarios. 2.4. Challenge #4 – Audit and compliance As network complexity inevitably increases, it's clear that we need to find ways of managing that complexity. Monitoring the status of individual network devices, logging into them individually, creating ad-hoc single-purpose automated scripting solutions is simply not enough. IP Fabric manages the assurance and compliance of your network, introducing an Intent- Based Networking approach to your network operations processes. 2.4.1. Challenge #4 detail Creation of an intent verification rule to validate configuration of following management protocols: • SNMP (communities, trap-hosts) • Syslog • AAA • NTP • NetFlow 2.4.2. Challenge #4 Acceptance criteria IP Fabric should collect accurate information for management protocols mentioned above. The appropriate intent-rules will be created and tested with every new discovery. IPF NOTE: To successfully collect management protocol configuration parameters, IP Fabric needs to have a service account available to access the running configuration of network devices. Incorrect configuration is anything other than the above, including no community string at all. 2.5. Challenge #5 – Rouge devices detection IP Fabric's intelligent network discovery process provides an answer to the fundamental question, what is in the network. Apart from automatically discovering managed network devices. The platform can provide insight into what is connected to the network and not managed by the IP Fabric platform. The Connectivity Matrix table provides detailed information about all connections via variety of protocols (CDP, LLDP, CEF, BGP, OSPF, IS-IS, etc.) managed or unmanaged. 2.5.1. Challenge #5 Detail After successful discovery, IP Fabric platform should provide accurate data in the Connectivity Matrix table to indicate what else is connected to the network and is not discovered by the platform. UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 5 2.5.2. Challenge #5 Acceptance criteria Accurate information will be provided in the Connectivity Matrix technology table. 3. IP Fabric Solution Overview IP Fabric automates network infrastructure data collection and provides predefined verifications that highlight your network's inconsistencies and issues. For a better overview of technology tables, there are links directed to IP Fabric's DEMO1 server. To access the DEMO1 server, please, use the following credentials with read-only access: Username: poc_testing Password: theTestingIsGreat2021 To use your environment for the hyperlinks, you can edit the following variable: Server variable: demo1.ipfabric.io 3.1. Solution architecture & System Requirements A distributed system of micro-service components resides within IP Fabric VM, all based around a multi-model database with a mathematical network model at its core. Operating system-level controls provide high availability, security, and log collection. The kernel- level bidirectional traffic shaper and application-level worker flow control mechanisms provide comprehensive traffic management and automatically respond to any sign of network congestion to ensure that only freely available bandwidth is utilized. The user interface is available on port 443 of the VM's IP address through any modern web browser and on any screen. Table output is exportable into CSV format, and reports are exportable into Word document format. UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 6 Picture 1: IP Fabric solution architecture The IP Fabric platform runs on Intel Xeon Nehalem CPUs or later. The system runs in at least four parallel threads, but scheduling can handle operations even down to a single thread. IP Fabric uses less than 4GB of RAM when idle, and an additional 12GB of RAM is required for collected network information. The base installation requires 50GB of HDD space and a further 50MB per device for the network. The following table represents the recommended hardware for optimum platform performance according to the network infrastructure devices in the network. Devices CPU RAM HDD (OS + DATA) 500 4 16 GB 90 GB (80G + 10G) 1 000 4 16 GB 100 GB (80G + 20G) 2 000 8 32 GB 200 GB (80G + 120G) 5 000 12 64 GB 300 GB (80G + 220G) 10 000 16 128 GB 550 GB (80G + 470G) 20 000 18 256 GB 1000GB (80G + 920G) Table 1: Host Hardware Requirements For more information, please, see the documentation online. 3.2. Discovery ready environment – prerequisites - important!! The discovery algorithm relies on Command-Line Interface (CLI) operational commands or API access for selected vendors. Following prerequisites are critical for successful discovery: • Infrastructure access credentials (username/password) o Correct username/password is critical for reading network data • CLI access UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 7 o All security paths have to be enabled to allow CLI connection from IP Fabric's source IP address to devices' management interfaces (Necessary ACLs or firewall rules need to be enabled before discovery) • High Privilege access, where possible o It is possible to discover network devices with low-privilege user access, but the discovery process may not collect specific data 3.3. Automated Discovery IP Fabric's discovery feature maps out the network infrastructure in a similar fashion as the network engineer would. Starting with a seed device, IP Fabric follows active network relationships to discover all existing paths, devices, and users naturally. With a fully automated advanced discovery algorithm, the platform crawls the network using SSH, Telnet, or API and collects operational and configuration data from all devices. This part of the process doesn't require Simple Network Management Protocol (SNMP), and it doesn't require any changes to the firewall either; all it needs to get to work is read-only credentials and access to the infrastructure. Picture 2: The discovery process flow: The IP Fabric solution massively reduces extensive network discovery time from months to just minutes. After successful discovery, the platform creates a mathematical model of the network from state and live network configuration data. The created network model or the snapshot has switching, routing, and security logic built-in permitting advanced visualization and network traffic path simulations, and more. For more information, please, see the documentation online. 3.4. Discovery Snapshots After successful discovery, the created network model or the snapshot has switching, routing, and security logic built-in permitting advanced visualization and network traffic path simulations, and more. Network snapshot records: • The complete digital network model • All service logs - logs used internally by the IP Fabric system and a record of commands issued on every network device. • Connectivity issues that had occurred during the retrieval of the snapshot. For more information, please, see the documentation online. UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 8 3.5. Network Site Separation By default, the site comprises the topology of all contiguously interconnected protocols, and the boundary of a site is formed by the network protocol relation that is not under management using the provided authentication credentials. The default Routing & Switching site separation is helpful for MPLS networks where directly connected routing infrastructure at the site's edge is not accessible Another option is to use a hierarchical set of regular expression rules matching the devices' hostnames and creating sites (device groups) accordingly. Correct/convenient separation is critical for high-level topology maps and logical device grouping. For more information, please, see the documentation online. 3.6. Inventory Tables The inventory tables provide an overview of sites, devices, modules, interfaces, and connected users/servers discovered within the network. It's an interactive environment for quick inventory and device analysis. Picture 3: Network device inventory in IP Fabric To access the inventory table: https://demo1.ipfabric.io/inventory/devices 3.7. Technology Tables Technology tables enable analysis and correlation of network state information and parameters on the fly. Most of the tables display live snapshot data generated by graph algorithms without a pre-existing cache. All tables are designed to handle large capacities and complex queries, so the outcome is likely to be better than analyzing the output in external applications like Excel. Exports to CSV format are available. UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 9 Picture 4: Technology > Port channels To access the port-channels table: https://demo1.ipfabric.io/technology/port- channels/member-status-table 3.8. Topology Diagrams The IP Fabric platform provides detailed technology drill-downs on dynamic network maps, helping users grasp the physical and logical connections between infrastructure devices in the network. Rather than presenting only the actual physical links between infrastructure devices, the model enables complete visibility on a protocol level (BGP, OSPF, EIGRP, LDP, STP, CDP, LLDP, RIB). UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 10 Picture 5: Multiprotocol network topology map 3.9. End-to-End Path simulation End to End application path testing is essential for any network or security operations when qualifying root cause analysis elements or verifying the post-migration state of selected security paths across the network. The IP Fabric platform enables seamless and fast path testing on the created mathematical model of the network. To access the end-to-end path simulation: https://demo1.ipfabric.io/graph/end-to-end- path Picture 6: End to End application path simulation UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 11 3.10. Intent-Verification Rules (Network Compliance) The platform provides detailed information about each technology or network protocol across all supported vendors and families. Apart from automated filters and easy search options, customized verification mechanisms may be created and included in the Assurance Engine. 3.11. Compliance Dashboard IP Fabric's automated intent-based rules combined with available historical correlations create a compelling ecosystem for fast and accurate network and security analytics. You can very comfortably create your verification control mechanisms for any supported technology or end-to-end path simulation with the platform. All data are available in the Network Assurance Dashboard and are continuously verified with every new snapshot of the network. To access compliance Dashboard: https://demo1.ipfabric.io/dashboard/overview Picture 7: Dashboard with intent-based rules 3.12. API Integration Undoubtedly, integration is an essential part of any network automation. IP Fabric's RESTful API supports API requests for any present data, increasing system versatility, usability, and the speed at which information is distributed. The system can act as a quick- and-easy integration interface for a variety of methods or user-scripts. With RESTful API, you get all of your data presented to you on a beautiful interface whenever you need it. IP Fabric supports standard token-based or user-based authentication flow. The OpenAPI/Swagger document is available, and alternatively, every technology table has its dynamic documentation. UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 12 Picture 8: Dynamic API documentation UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 13 4. Acceptance Criteria Review After the Proof-of-Concept process, the testing team will complete the Acceptance Review for all defined challenges. Challenge Score Reason (PASS/FAIL) #1 Collected data accuracy #2 E2E path simulation #3 Troubleshooting, RCA #4 Intent-based rules #5 Rogue devices detection 4.1. Conclusion Summary [conclusion to be added] ……………………… ……………………… Signed for IP Fabric Signed for TEHIK UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 14 Non-Disclosure Agreement 1. The parties mutually undertake to keep secret and not disclose to third parties any information considered confidential that has been obtained from the other party in the course of the contract, or otherwise while working together or accidentally. 2. The IP Fabric must take organisational, physical, and IT-security measures to protect personal data and TEHIK's information systems in accordance, inter alia, with the applicable legislation. IP Fabric shall not process any personal data that falls under the jurisdiction of GDPR other than names and contact information of TEHIK's employees. 3. In the event that the processing of personal data becomes necessary during the contract, the parties shall agree on the terms and conditions of the processing of personal data in the contract for processing personal data, guided by Article 28 of the GDPR. 4. Confidential information is any information (including trade secrets, personal data, contract data, information systems, security system specifications, hardware and software specifications, tenders, technologies used, specifications, etc.) obtained in connection with the performance of the contract, the disclosure of which to third parties could expose the parties to security risks, economic damage, or breach of privacy of third parties (in particular the buyer's customers). In the event of doubt, the confidentiality of the information shall be presumed. 5. Confidential information is not information the disclosure of which is required by law or which the parties have agreed to disclose. 6. The IP Fabric shall not engage in public relations in relation to the contract and shall not make any announcements to the press, electronic media, the general public, or other audiences except with the prior written consent by TEHIK. 7. The parties may communicate confidential information only to those persons who are involved in the performance of the contract and shall ensure that these persons are aware of the obligation of confidentiality. The parties shall require such persons to comply with this obligation unconditionally and indefinitely. 8. The parties shall not use any confidential information which has come to their knowledge in the course of the performance of the contract for their own benefit or for any other purpose than the performance of the contract. 9. IP Fabric is aware that the contracts and agreements are public except for those parts which have been designated for internal use under the Estonias Public Information Act or marked by the IP Fabric as trade secrets. 10. In the event of a breach of confidentiality, IP Fabric undertakes to compensate TEHIK or any third party for any loss or damage suffered by TEHIK or any third party as a result of such breach, irrespective of whether the breach occurred during the term of the contract or after the termination of the contractual obligations. The compensation is limited to the value of 30 000 euros. 11. The obligation of confidentiality shall apply indefinitely. Date: Signature: ……………………………… ……………………………… IP Fabric TEHIK UATP_TEHIK.docx, 11.11.2021 , v1.2 Page 15
Allikas: Tervise- ja heaolu infosüsteemide keskus dokumendiregister →
dokumendiregister.eeAsutusedEesti avalike dokumendiregistrite otsing · nimistu.ee andmetel