|
Based
on practical considerations, such as ease of
implementation, database support, and
processing needs, we aimed to develop a
model that allows view-based access
control. Users of the database system
should be able to access predefined sets of
views, based on their authorizations.
Views are built from a multi-level
database and may be updated, according to
the users’ privileges.
Any update is then propagated back to
the multi-level relation.
Note, that although there are several
related issues, such as inference and covert
channel problem and concurrency control, in
this work we focus mainly on the design
principles of the multi-level secure system
and its applicability for GIS.
First, we considered different
architectures for storing data and different
methods to define security objects (views).
In
particular we studied three different
security architectures:
- Single Multi-Level Database (Multi-Level Relations)
- Replicated Multi-Level Database
- Single Multi-Level Database (Uni-Level Relations)
1.
Single Multi-Level Database (Multi-Level
Relations)
The
straightforward model for multi-level
database architecture would be a single
database, storing and manipulating data
classified at different levels. ArcSDETM
administration commands have been used to
define different views of the base relations
with different privileges, and users would
be able to access these predefined views
only according to their access permissions
(privileges).
Updates would be propagated back to
the main database. This approach served
perfectly well for secure data viewing;
unfortunately, we experienced a major
shortcoming of this model.
Views, created by ArcSDETM
are not updateable by the GIS software
(ArcMap). Hence, low-level users cannot add
or delete any feature while viewing the data
layer (feature class) in ArcMap.
2.
Replicated Multi-Level Database
This
model is based on separating the data into
several databases, according to the
classification of the data (Figure 4).
Any lower level data is replicated at
the higher level, thus allowing the users to
see a complete database at their clearance
level.
The problem with this model is that
it requires large storage overhead, and the
propagation of updates from low-level
databases to the higher levels is expensive.
Nevertheless, this is one of the most secure
models to be implemented.
We
considered an update propagation method
where all updates are logged. Low-level updates are then applied at periodic intervals on
the higher security data.
Clearly, in addition to the
maintenance of the replicated data, we need
to address issues like conflict resolution,
where two updates occur on the same data
item at different levels.
Although we did not completely
abandon this model, we consider it too
expensive to implement.
3.
Single Multi-Level Database (Uni-Level
Relations)
We
had the greatest success by using the
architecture that separates data into single
level relations (Figure 5).
In this model, when a user accesses
the database, the database is constructed
from single-level relations, such that the
user can access data at the appropriate
level.
After the user’s session
terminates, the composite database is
decomposed into several single-level
relations, according to the security
classifications of the data.
Although
at this stage of the work we have not
implemented the modules that combine and
decompose the data, we have a system working
that allows separating data into
single-level relations.
GIS users can project these relations
on top of each other.
This gives the feeling that the user
accesses a single relation including data
classified at different levels, while in
reality this is only a projection of
independent data.
Since
there is only one copy of each data item,
concurrency control and update propagation
is simplified.
However, we are aware of the need to
provide tools to seamlessly manipulate data
to provide a combined view to the users.
In summary, we found
that it is possible to provide a smaller
granularity access control than file-level
to GIS data. However, this is not
straightforward, and the GIS software gives
minimal support. We see two possible
directions for improvement:
- Improved support for incorporating traditional
database technology into GIS. This would
allow the use of existing database
technology to secure GIS applications.
On the other hand, this approach
requires that the effort to protect
confidential data be initiated by the
GIS vendors.
- A different solution could be to improve our
preliminary system based on the
combination and decomposition of
single-level relations. We believe that
software packages to perform these
functions can be developed and used as
wrappers on top of the GIS software.
|
