Transcript 6PGEEIDE Design Considerations

EIDE Design Considerations
Brian Wright
Portland General Electric
1
EIDE Design Considerations
Introduction

Focus on physical design, not on application
development.

Planned Topics
1. Hardware Configuration
2. Location and Function Of Application
Modules
3. Data Connectivity
4. Cryptography Basics
2
EIDE Design Considerations
Glossary & Acronyms

LAN – Local Area Network
– Collection of computers within one domain, secured from outside connections.

WAN – Wide Area Network
–

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.

Firewall
– A system designed to prevent unauthorized access to or from a private
network. Firewalls can be implemented in both hardware and software,

HTTP - HyperText 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.
3
EIDE Design Considerations
Glossary & Acronyms

UTF - Universal Transformation Format
– a method of converting Unicode characters, which are 16 bits each, into 7- or 8bit characters. UTF-7 converts Unicode into ASCII for transmission over 7-bit
mail systems, and UTF-8 converts Unicode to 8-bit bytes.

DBMS – Database Management System
– A collection of programs that enables you to store, modify, and extract
information from a database

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.
4
EIDE Design Considerations
Hardware Configuration
Simple System
 Secure System
 Secure Redundant System

5
EIDE Design Considerations
Simple System



Firewall
Internet

Server
Web
Listener

EIDE
Sender

EIDE
Receiver
Data Store
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
EIDE Design Considerations
Simple System
ADVANTAGES



Simple to configure
Lower Hardware
Costs
No special
requirements on
external entities
DISADVANTAGES


Direct access from
internet allowed to
LAN server
No redundancy,
down time can be
expected for
upgrades and failures
7
EIDE Design Considerations
Secure System


DMZ Server
Internet
Firewall
DMZ
Firewall
Web
Listener
Internet

EIDE
Proxy
LAN Server

EIDE
Receiver
Data Store
EIDE
Sender
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
EIDE Design Considerations
Secure System
ADVANTAGES


No direct access to
LAN servers from
internet.
No special
requirements on
external entities
DISADVANTAGES


Additional
Administration
No redundancy,
down time can be
expected for
upgrades and failures
9
EIDE Design Considerations
Secure
Redundant
System

Virtual IP
Internet
Content Switches

Internet
Firewall
DMZ Server
DMZ Server
Web
Listener
Web
Listener
EIDE
Proxy
EIDE
Proxy

LAN Server
EIDE
Sender
EIDE
Receiver
Content Switch
Clustered Data Server
Data Store

Virtual IP
Content Switch
DMZ
Firewall
EIDE Design Considerations
LAN Server
EIDE
Receiver
EIDE
Sender
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


Heart Beat
DBMS Server
Node 1
DBMS Server
Node 2


Storage Controller
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
EIDE Design Considerations
Secure Redundant System
ADVANTAGES


Majority of
maintenance can
occur while system is
in operation
Fault Tolerance
DISADVANTAGES


Complexity in
Administration
Additional Hardware
Costs
12
EIDE Design Considerations
Data Connectivity



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/WeatherSummary.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.
13
EIDE Design Considerations
Data Connectivity
Messaging : If using Microsoft platform use Microsoft
Message Queue (MSMQ) for cross server
communications, or Java Message Service for other
platforms
 Raises events within application.
 Messages remain in queue until read or message life
expires. Allowing processing to be single threaded,
avoiding collisions from multiple requests
 Messages have priority, read from queue in highest
priority first. Messages with same priority are read first
in first out.
 Messaging can be made fault tolerant. Allowing
messages to be delivered even if there was a temporary
outage.
 MSMQ Triggers automatically associate incoming
messages in a queue with functionality in a COM
component or standalone .exe
14
EIDE Design Considerations
Data Connectivity
Messaging Usage:
 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.
 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.
 If willing to forgo the persistent cache provided by the
data store, the messages could contain the data.
 Many object oriented languages have the ability to
serialize an object. This serialize object would be the
payload of a message.
15
EIDE Design Considerations
Cryptography Basics
Encryption/Decryption
 Symmetric vs Asymmetric
 XML Canonicalization
 Signing

16
EIDE Design Considerations
Cryptography Basics
Encryption/Decryption
P: Plain Text
C: Cypher Text
K: Key
F: Encryption Algorithm (DES, RSA)
Encryption F(P,K) = C
 Decryption F(C, K) = P

17
EIDE Design Considerations
Cryptography Basics
Symmetric vs Asymmetric
SYMMETRIC



Same key uses for
encryption and
decryption.
Key must be known
by both parties
Relative inexpensive
in resource utilization
ASYMMETRIC




Encryption by private
key
Decryption by public
key
Sender is owner of
keys
Expensive in
resource utilization
18
EIDE Design Considerations
Cryptography Basics
XML Canonicalization
Two XML messages can be formatted
differently but contain the same
information. Canonicalization reformats
them identically.
 Whitespace normalized
 <ScheduleType/> becomes
<ScheduleType></ScheduleType>
 Attributed values delimited by double
quotes
 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
 Plain Text canonicalized and hashed to fix length string
 Hash encrypted using private key producing the signature
 Send plain text and signature
Receiver
 Plain Text canonicalized and hashed to fix length string
 Request Public key from sender
 Decrypts signature and compares hash values
20
EIDE Design Considerations
Discussion
One of many designs
 Not specific to a technology or operating
system
 Web Services
 NT Services or Unix Daemons
 Triggers

21
EIDE Design Considerations
QUESTIONS?
22
EIDE Design Considerations