EIDE Design Considerations Brian Wright Portland General Electric
EIDE Design Considerations Brian Wright Portland General Electric EIDE Design Considerations 1
Introduction l Focus on physical design, not on application development. l Planned Topics 1. Hardware Configuration 2. Location and Function Of Application Modules 3. Data Connectivity 4. Cryptography Basics EIDE Design Considerations 2
Glossary & Acronyms l LAN – Local Area Network – Collection of computers within one domain, secured from outside connections. l WAN – Wide Area Network – l Collection of computer domains, with security between domains. DMZ - Demilitarized Zone – A small subnetwork that sits between a trusted internal network, such as a corporate private LAN, and an untrusted external network, such as the public Internet. l Firewall – A system designed to prevent unauthorized access to or from a private network. Firewalls can be implemented in both hardware and software, l HTTP - Hyper. Text Transfer Protocol, – the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions server applications and their client applications should take in response to various commands. EIDE Design Considerations 3
Glossary & Acronyms l UTF - Universal Transformation Format – a method of converting Unicode characters, which are 16 bits each, into 7 - or 8 bit characters. UTF-7 converts Unicode into ASCII for transmission over 7 -bit mail systems, and UTF-8 converts Unicode to 8 -bit bytes. l DBMS – Database Management System – A collection of programs that enables you to store, modify, and extract information from a database l COM – Component Object Model – A software architecture developed by Microsoft to build componentbased applications. COM objects are discrete components, each with a unique identity, which expose interfaces that allow applications and other components to access their features. EIDE Design Considerations 4
Hardware Configuration Simple System l Secure Redundant System l EIDE Design Considerations 5
Simple System l l l EIDE Design Considerations Single LAN Server Web Listener receives incoming requests and gives it to the receiver Data store caches meter and schedule data to be sent or received EIDE Receiver parses the received XML document and writes to the Data Store EIDE Sender reads from the Data Store, builds the XML document , and sends to the external entity The EIDE applications are where the logic is placed, related to managing request to send or receive data 6
Simple System ADVANTAGES l l l Simple to configure Lower Hardware Costs No special requirements on external entities EIDE Design Considerations DISADVANTAGES l l Direct access from internet allowed to LAN server No redundancy, down time can be expected for upgrades and failures 7
Secure System l l EIDE Design Considerations DMZ Server – Limited firewall protection, IP address is masked LAN Server – High firewall protection. Generally configured to allow no direct internet connections inside EIDE Proxy provides received application xml validation, document canonicalization and signing. EIDE Receiver inspects signature to validate message originator 8
Secure System ADVANTAGES l l No direct access to LAN servers from internet. No special requirements on external entities EIDE Design Considerations DISADVANTAGES l l Additional Administration No redundancy, down time can be expected for upgrades and failures 9
Secure Redundant System l l EIDE Design Considerations Content switches provides load balancing and failover to the dual servers Virtual IP address provides single address to content switches Cross connectivity allows maintenance of servers while other node in service Data store is now required to be shared within its own database cluster. 10
Data Store Cluster l l EIDE Design Considerations Two or more servers can be clustered together in an active-passive system. The DBMS is defined into an application group for failover. Storage Controller contains the disk array and are manufactured with fault tolerant features. For fault tolerance in the disk arrays, recently they raid level 0+1 or 10 11
Secure Redundant System ADVANTAGES l l Majority of maintenance can occur while system is in operation Fault Tolerance EIDE Design Considerations DISADVANTAGES l l Complexity in Administration Additional Hardware Costs 12
Data Connectivity l l l HTTP protocol works best when crossing a firewall. To assist with security, may want to use a non-standard port for crossing the DMZ to LAN firewall. http: //4. 5. 30. 209: 22100/Weather. Summary. html Primary development of content switches were to manage load balancing of server farms for the web, http Do not have any database connectivity cross the firewall. EIDE Design Considerations 13
Data Connectivity Messaging : If using Microsoft platform use Microsoft Message Queue (MSMQ) for cross server communications, or Java Message Service for other platforms l Raises events within application. l Messages remain in queue until read or message life expires. Allowing processing to be single threaded, avoiding collisions from multiple requests l Messages have priority, read from queue in highest priority first. Messages with same priority are read first in first out. l Messaging can be made fault tolerant. Allowing messages to be delivered even if there was a temporary outage. l MSMQ Triggers automatically associate incoming messages in a queue with functionality in a COM component or standalone. exe EIDE Design Considerations 14
Data Connectivity Messaging Usage: l If EIDE Receiver is a service, it would have a no blocking listener on a queue that EIDE proxy would write to, and send a message to the applications that they have data now available. l If EIDE Sender is a service, the application that request a transfer externally would write the data to the data store and send a message to EIDE Sender to perform a transfer. l If willing to forgo the persistent cache provided by the data store, the messages could contain the data. l Many object oriented languages have the ability to serialize an object. This serialize object would be the payload of a message. EIDE Design Considerations 15
Cryptography Basics Encryption/Decryption l Symmetric vs Asymmetric l XML Canonicalization l Signing l EIDE Design Considerations 16
Cryptography Basics Encryption/Decryption P: Plain Text C: Cypher Text K: Key F: Encryption Algorithm (DES, RSA) Encryption F(P, K) = C l Decryption F(C, K) = P l EIDE Design Considerations 17
Cryptography Basics Symmetric vs Asymmetric SYMMETRIC l l l Same key uses for encryption and decryption. Key must be known by both parties Relative inexpensive in resource utilization EIDE Design Considerations ASYMMETRIC l l Encryption by private key Decryption by public key Sender is owner of keys Expensive in resource utilization 18
Cryptography Basics XML Canonicalization Two XML messages can be formatted differently but contain the same information. Canonicalization reformats them identically. l Whitespace normalized l <Schedule. Type/> becomes <Schedule. Type></Schedule. Type> l Attributed values delimited by double quotes l UTF encoding EIDE Design Considerations 19
Cryptographic Basics Signing (Digital Signature) Process validates that data has not been tampered and the data is from the sender. Sender l Plain Text canonicalized and hashed to fix length string l Hash encrypted using private key producing the signature l Send plain text and signature Receiver l Plain Text canonicalized and hashed to fix length string l Request Public key from sender l Decrypts signature and compares hash values EIDE Design Considerations 20
Discussion One of many designs l Not specific to a technology or operating system l Web Services l NT Services or Unix Daemons l Triggers l EIDE Design Considerations 21
QUESTIONS? EIDE Design Considerations 22
- Slides: 22