With the popularization of computers and the development of the Internet, databases are no longer just a topic reserved for programmers. The Oracle database has already occupied a place in the database market with its excellent performance, convenient and flexible operation. However, with the continuous advancement of network technology and the continuous increase of data information, data security is no longer the "old talk" of the past, nor is it the "out of reach" regulations in the previous books.
Perhaps a long time ago, everyone felt that there was no hidden danger in the security of Oracle database, because the slogan put forward by Oracle when it began to promote its database software in November last year was "Only Oracle9i can achieve absolute security." But regardless of whether it said this for promotion or to expand its popularity, in December last year, British security expert David Litchfield discovered a buffer overflow vulnerability caused by a program error in 9iAS, and later, PenTest Limited and eEye Digital Security each proposed A small loophole has been discovered, and everyone who uses Oracle's products can't help but tense up their originally relaxed brains - for users, after all, this is related to their "net worth and life".
Next, the author will take you into the world of Oracle data security. Due to the limited level of the author, deficiencies are inevitable, and I hope you will give me your advice.
(1) Some basic common sense about Oracle database.
This is just to lay some foundation for future security, because we will use them later. Haha~!
1. Components included
in Oracle In Oracle, database refers to the entire Oracle RDBMS environment, which includes the following components:
·Oracle database process and buffer (instance).
·The SYSTEM tablespace contains a centralized system category, which can be composed of one or more data files.
·Other table spaces defined by the database administrator (DBA) (optional), each consisting of one or more data files.
·More than two online recovery logs.
·Archive recovery logs (optional).
·Other files (control files, Init.ora, Config.ora, etc.).
Each Oracle database runs on a central system catalog and data dictionary, which is located in the SYSTEM tablespace.
2. About "log"
Oracle database uses several structures to protect data: database backup, log, rollback segment and control file. Below we will take a general look at the "log" as one of the main structures:
Each Oracle database instance provides a log that records all modifications made in the database. Each running Oracle database instance has an online log corresponding to it, which works together with the Oracle background process LGWR to immediately record all modifications made by the instance. Archiving (offline) logs is optional. Once the online logs of an Oracle database instance are filled up, an online log archive file can be formed. Archived online log files are uniquely identified and merged into archived logs.
·About online logs: Each instance of an Oracle database has an associated online log. An online log consists of multiple online log files. The online redo log file is filled with redo entries, and the data recorded in the log entries is used to reconstruct all modifications made to the database.
·About archive logs: When Oracle wants to archive a filled online log file group, it must create an archived redo log. It has the following uses for database backup and recovery:
<1> Database backup and online and archive log files can ensure that all submitted transactions can be recovered in the event of operating system and disk failures.
<2>With the database open and normal system use, if the archive log is permanently saved, online backup can be performed and used.
The database can run in two different modes: NOARCHIVELOG mode or ARCHIVELOG mode. When the database is used in NOARCHIVELOG mode, online log archiving cannot be performed. If the database is running in ARCHIVELOG mode, online log archiving can be implemented.
3. Physical and logical storage structure
Oracle RDBMS is composed of table spaces, and table spaces are composed of data files. Tablespace data files are formatted in internal block units. The block size is set by the DBA when Oracle is first created and can vary from 512 to 8192 bytes. When an object is created in an Oracle tablespace, the user uses units called lengths (initial extent, next extent, min extents, and max extents). To indicate the space size of the object. The size of an Oracle length can vary, but it must contain a chain composed of at least five consecutive blocks. (2)
Oracle data security maintenance
I remember a philosopher said: "Things are Change is inseparable from internal and external factors." So the topic of Oracle data security must be divided into two parts: "internal" and "external". Well, let's start with "internal": 1
. Starting from the Oracle system itself,
let’s put aside the notorious “hacker” and other external reasons, and think about our database first. What hard disk is damaged, what software is damaged, what operating things... a series of reasons System problems caused by our "negligence" can completely destroy the data in the database we have worked so hard to build. So, let's find out the reasons from ourselves first. [1] Methods to solve the problems of the system
itself --Database backup and recovery
·Database backup:
Regarding the backup of Oracle database, there are three standard methods: export/import (Export/Import), cold backup, and hot backup. Export backup is a logical backup, while cold backup and hot backup are physical backups.
<1>Export/Import (Export/Import)
Use Export to extract data from the database, and use Import to send the extracted data back to the Oracle database.
a. Simple export data (Export) and import data (Import)
Oracle supports three types of output:
(1) Table mode (T mode), export data from the specified table.
(2) User mode (U mode), export all objects and data of the specified user.
(3) Full database mode (Full mode), export all objects in the database.
The process of data export (Import) is the reverse process of data import (Export), and their data flow directions are different.
b. Incremental export/import
Incremental export is a commonly used data backup method. It can only be implemented for the entire database and must be exported as SYSTEM. No questions are asked for this export. The default export file name is export.dmp. If you do not want your output file to be named export.dmp, you must specify the file name to be used on the command line.
Incremental export includes three types:
(1) "Complete" incremental export (Complete)
means backing up the entire database, such as:
$exp system/manager inctype=complete file=990702.dmp
(2) "Incremental" incremental export backs up
data changed since the last backup. For example:
$exp system/manager inctype=incremental file=990702.dmp
(3) "Cumulative" incremental export (Cumulative)
The cumulative export method only exports the information that has changed in the database since the last "complete" export. For example:
$exp system/manager inctype=cumulative file=990702.dmp
The database administrator can schedule a backup schedule and use three different methods of data export to complete it reasonably and efficiently. For example, the database backup task can be arranged as follows:
· Monday: full export (A)
· Tuesday: incremental export (B)
· Wednesday: incremental export (C)
· Thursday: incremental export (D)
· Friday: cumulative Export (E)
· Saturday: Incremental export (F)
· Sunday: Incremental export (G)
If the database is accidentally damaged on Sunday, the database administrator can follow the following steps to restore the database:
Step 1: Use the command CREATE DATABASE regenerates the database structure;
Step 2: Create an additional loop segment that is large enough.
Step 3: Completely incremental import A:
$imp system./manager inctype= RECTORE FULL=Y FILE=A
Step 4: Cumulative incremental import E:
$imp system./manager inctype= RECTORE FULL=Y FILE =
Eth Step 5: Import the latest incremental F:
$imp system/manager inctype=RESTORE FULL=Y FILE=F
<2>Cold backup
Cold backup occurs when the database has been shut down normally. When it is shut down normally, it will provide us with a complete database. Cold backup is a way of copying critical files to another location. Cold backup is the fastest and most secure method for backing up Oracle information. The advantages of cold backup are:
· It is a very fast backup method (just copy the files)
· It is easy to archive (a simple copy is enough)
· It is easy to restore to a certain point in time (just copy the files back)
· It can be combined with archiving Methods are combined to restore the "latest state" of the database.
·Low maintenance, high security.
However, cold backup also has the following shortcomings:
·When used alone, it can only provide recovery to "a certain point in time".
·During the entire process of implementing backup, the database must be backed up and no other work can be performed. In other words, during the cold backup process, the database must be closed.
·If the disk space is limited, it can only be copied to other external storage devices such as tapes, and the speed will be very slow.
·Cannot be restored by table or by user.
If possible (mainly based on efficiency), the information should be backed up to disk, then start the database (so that users can work) and copy the backed up information to tape (while copying, the database can also work). The files that must be copied in the cold backup include:
·All data files
·All control files
·All online REDO LOG files
·Init.ora file (optional)
It is worth noting that the cold backup must be performed with the database closed. When the database is in When the database file system backup is open, it is invalid to perform a database file system backup. The
following is a complete example of doing a cold backup:
(1) Shut down the database $sqldba lmode=y
SQLDBA >connect internal;
SQLDBA >shutdown normal;
(2) Use the copy command to back up all Time files, redo log files, control files, initialization parameter files
SQLDBA >! cp < file > < backup directory >
(3) Restart the Oracle database
$sqldba lmode=y
SQLDBA >connect internal;
SQLDBA >startup;
<3>Hot backup
Hot backup is a method of backing up data using archivelog mode while the database is running. Therefore, if you have a cold backup from last night and today's hot backup file, you can use these data to restore more information when a problem occurs. Hot backup requires the database to operate in Archivelog mode and requires a large amount of archive space. Once the database is running in the archivelog state, a backup can be made. The hot backup command file consists of three parts:
1. Data files are backed up table space by table space.
(1) Set the table space to the backup state
(2) Back up the data files of the table space
(3) Restore the table space to the normal state
2. Back up archived log files.
(1) Temporarily stop the archive process
(2) Log files in the archive redo log target directory
(3) Restart the archive process
(4) Back up the archived redo log files
3. Use the alter database backup controlfile command to back up copy files.
The advantages of hot backup are:
· It can be backed up at the table space or data file level, and the backup time is short.
·The database can still be used during backup.
·Achieving second-level recovery (recovery to a certain point in time).
·Can restore almost all database entities.
·Recovery is fast and in most cases occurs while the database is still working.
The shortcomings of hot backup are:
·Cannot make mistakes, otherwise the consequences will be serious.
·If the hot backup is unsuccessful, the results cannot be used for point-in-time recovery.
·Because it is difficult to maintain, special care must be taken and "ending in failure" is not allowed.
(2) Another hidden danger from the inside - user management and password issues
here. In fact, as a database administrator, I know very well that the Oracle database itself uses many methods to enhance the security of the database. It is often seen that There are passwords, roles, permissions, etc. So let’s start with the simplest DBSNMP:
If the Oracle database adopts a typical installation, a user called DBSNMP is automatically created. This user is responsible for running the Intelligent Agent (Intelligent Agent) of the Oracle system. The default password of this user is also " DBSNMP". If you forget to change the user's password, anyone can access the database system through this user. Now let's take a look at what permissions and roles this user has, and then analyze the damage this user may cause to the database system.
Start the SQL/PLUS program and log in as this user:
You can see that this user is not a SYS or SYSTEM administrative user. However, it has two system-level permissions: UNLIMITED TABLESPACE and CREATE PUBLIC SYNONYM.
When you see these two permissions, you should immediately think that these are security risks, especially UNLIMITED TABLESPACE, which is one of the attack points that destroys the database system. If you still think that even if someone uses this unmodified password to log in to the database, there will be no loss, I have to remind you: this user has UNLIMITED TABLESPACE system permissions, and it can write a small script. Then maliciously fill the system with junk data, so that the database system cannot run and will directly lead to the final paralysis. At present, many database systems require 24/7 operation. If the system is filled with junk data, then by the time the database system is restored, irreparable losses may have been caused.
But besides DBSNMP, there are many other users, what should I do? Let us first take a look at the user management problems currently common in Oracle databases:
(1) Excessive permissions: General users who program and browse the ORACLE database often have DBA (database administrator permissions) and can make any modifications to the database system. or delete.
(2) Poor security: The default storage location of many ORACLE users is in the system table space. This not only affects the normal operation of the system, but also affects the data information of different users, makes them transparent and has poor confidentiality. As data continues to be added, it is possible for the entire database system to collapse.
(3) Passwords are regular: The bad habit of consistent user names and passwords formed in the early days of ORACLE debugging remains to this day; the passwords of system users SYS and SYSTEM are also known to everyone.
Knowing these common "problems", what should we do? Here are some of my suggestions:
(1) ORACLE DBA (database administrator) specifications
·The ORACLE user password under the SUN Solaris operating system should be kept strictly confidential and the password should never be set to ORACLE; a dedicated database administrator should be designated to change it regularly.
·The SYS and SYSTEM system administrator user passwords created by ORACLE initialization should be changed from the original MANAGER to other strings that are not easy to remember.
·The management port of ORACLE WEB SERVER has the ability for DBA to browse the database. Therefore, the password of its administrator ADMIN should also be kept secret. The password should not be set to MANAGER; and a dedicated database administrator should be designated to change it regularly.
·ORACLE DBA is best managed using a window-based interface on the SUN SPARC server console. The premise is that the ORACLE user starts the server, and then enters SVRMGRM in the window command line, which starts the ORACLE SERVER MANAGER menu management; after logging in with the SYSDBA identity, you can do database system maintenance work (2) SQL*PLUS programming
users Specification
·Specification of storage structure.
Considering that SQL*PLUS programming can meet the diverse application needs of various industries, companies, and departments, our SQL*PLUS programming users should also standardize in this direction: different types of applications must There are different users; different types of applications must have different storage locations, including the creation and planning of physical files, default table spaces, and temporary table spaces: When preparing to write a certain large-scale (from ORACLE data volume and user-oriented volume When considering an application, you should first create a logical storage location - a table space, and define the storage path of the physical files and the size of the hard disk occupied.
①. The default storage path of physical files is under /oracle_home/dbs. Use the UNIX command df -k on the command line to check the usage of hard disk resource partitions. If the oracle_home usage rate reaches more than 90‰, and there are one or more relatively free hard disk resource partitions that can be used, we'd better change the default storage path of the physical files to the relatively free hard disk resource partition path. Under this path, we can plan the storage of resource physical files like this:
xxx table space
xxx industry/xxx company/xxx department/xxx service.dbf
DEMO table space
default_datafile_home1/col /elec/sys4/demo1.dbf
default_datafile_home1/col /elec/ sys4/demo2.dbfCompany
system four simulation demonstration system physical file
HUMAN table space
default_datafile_home1/col/elec/human/human.dbfCompany
personnel department personnel management system physical file
BOOK table space
default_datafile_home1/col/elec/book/
book.dbfcompany Data room library management system physical file
QUESTION table space
default_datafile_home1/col/elec/client/question.dbfCompany
customer service department question library system physical file
PC table space
default_datafile_home1/col/chaoxun/client/pc.dbf
The physical files of the company’s PC after-sales service system
... table space
default_datafile_home2/…………………
and so on
. Description: where default_datafile_home1 refers to oracle_home/dbs; default_datafile_home2 refers to the relatively free hard disk resource partition path.
②. The size of the physical file is determined according to the amount of data, data objects, and program packages of the application system. Generally used for small systems that simulate demonstrations, the initial physical file in the table space is 2M to meet the requirements. If the amount of information is full, physical files can be added to expand the table space (the size of each expansion can also be tentatively set to 2M); generally The actual running application system can appropriately increase the initial physical file size of the table space, but do not allocate too large a time (because it is not easy to recycle space, but it is easy to expand the space). This also needs to be analyzed based on the specific situation: the amount of information is large, and it takes a long time. For applications that save time, if conditions permit, the table space can be as large as hundreds of MB or even GB; for applications with small amounts of information and frequent short-term refreshes, the table space can be controlled below 2 MB.
③. The name of the table space should use English characters or character abbreviations similar to those used in the system. The name of one or more physical files corresponding to the table space should also be relevant. If different users are in different default table spaces, the stored information cannot access each other. This is much more secure than storing all user information in the system table space. If a user is created using the ORACLE WEB SERVER management port, the default and temporary table spaces must be system table spaces. The DBA must remember to change the user's default table space. Temporary table spaces store temporary data segments and handle some intermediate operations such as sorting and merging. They can be placed in specially created table spaces according to actual application requirements; if the system table space is large, they can also be placed in the system table space. It is best to store data indexes created by users in different table spaces separately from data files to reduce data contention and improve response speed.
Perhaps a long time ago, everyone felt that there was no hidden danger in the security of Oracle database, because the slogan put forward by Oracle when it began to promote its database software in November last year was "Only Oracle9i can achieve absolute security." But regardless of whether it said this for promotion or to expand its popularity, in December last year, British security expert David Litchfield discovered a buffer overflow vulnerability caused by a program error in 9iAS, and later, PenTest Limited and eEye Digital Security each proposed A small loophole has been discovered, and everyone who uses Oracle's products can't help but tense up their originally relaxed brains - for users, after all, this is related to their "net worth and life".
Next, the author will take you into the world of Oracle data security. Due to the limited level of the author, deficiencies are inevitable, and I hope you will give me your advice.
(1) Some basic common sense about Oracle database.
This is just to lay some foundation for future security, because we will use them later. Haha~!
1. Components included
in Oracle In Oracle, database refers to the entire Oracle RDBMS environment, which includes the following components:
·Oracle database process and buffer (instance).
·The SYSTEM tablespace contains a centralized system category, which can be composed of one or more data files.
·Other table spaces defined by the database administrator (DBA) (optional), each consisting of one or more data files.
·More than two online recovery logs.
·Archive recovery logs (optional).
·Other files (control files, Init.ora, Config.ora, etc.).
Each Oracle database runs on a central system catalog and data dictionary, which is located in the SYSTEM tablespace.
2. About "log"
Oracle database uses several structures to protect data: database backup, log, rollback segment and control file. Below we will take a general look at the "log" as one of the main structures:
Each Oracle database instance provides a log that records all modifications made in the database. Each running Oracle database instance has an online log corresponding to it, which works together with the Oracle background process LGWR to immediately record all modifications made by the instance. Archiving (offline) logs is optional. Once the online logs of an Oracle database instance are filled up, an online log archive file can be formed. Archived online log files are uniquely identified and merged into archived logs.
·About online logs: Each instance of an Oracle database has an associated online log. An online log consists of multiple online log files. The online redo log file is filled with redo entries, and the data recorded in the log entries is used to reconstruct all modifications made to the database.
·About archive logs: When Oracle wants to archive a filled online log file group, it must create an archived redo log. It has the following uses for database backup and recovery:
<1> Database backup and online and archive log files can ensure that all submitted transactions can be recovered in the event of operating system and disk failures.
<2>With the database open and normal system use, if the archive log is permanently saved, online backup can be performed and used.
The database can run in two different modes: NOARCHIVELOG mode or ARCHIVELOG mode. When the database is used in NOARCHIVELOG mode, online log archiving cannot be performed. If the database is running in ARCHIVELOG mode, online log archiving can be implemented.
3. Physical and logical storage structure
Oracle RDBMS is composed of table spaces, and table spaces are composed of data files. Tablespace data files are formatted in internal block units. The block size is set by the DBA when Oracle is first created and can vary from 512 to 8192 bytes. When an object is created in an Oracle tablespace, the user uses units called lengths (initial extent, next extent, min extents, and max extents). To indicate the space size of the object. The size of an Oracle length can vary, but it must contain a chain composed of at least five consecutive blocks. (2)
Oracle data security maintenance
I remember a philosopher said: "Things are Change is inseparable from internal and external factors." So the topic of Oracle data security must be divided into two parts: "internal" and "external". Well, let's start with "internal": 1
. Starting from the Oracle system itself,
let’s put aside the notorious “hacker” and other external reasons, and think about our database first. What hard disk is damaged, what software is damaged, what operating things... a series of reasons System problems caused by our "negligence" can completely destroy the data in the database we have worked so hard to build. So, let's find out the reasons from ourselves first. [1] Methods to solve the problems of the system
itself --Database backup and recovery
·Database backup:
Regarding the backup of Oracle database, there are three standard methods: export/import (Export/Import), cold backup, and hot backup. Export backup is a logical backup, while cold backup and hot backup are physical backups.
<1>Export/Import (Export/Import)
Use Export to extract data from the database, and use Import to send the extracted data back to the Oracle database.
a. Simple export data (Export) and import data (Import)
Oracle supports three types of output:
(1) Table mode (T mode), export data from the specified table.
(2) User mode (U mode), export all objects and data of the specified user.
(3) Full database mode (Full mode), export all objects in the database.
The process of data export (Import) is the reverse process of data import (Export), and their data flow directions are different.
b. Incremental export/import
Incremental export is a commonly used data backup method. It can only be implemented for the entire database and must be exported as SYSTEM. No questions are asked for this export. The default export file name is export.dmp. If you do not want your output file to be named export.dmp, you must specify the file name to be used on the command line.
Incremental export includes three types:
(1) "Complete" incremental export (Complete)
means backing up the entire database, such as:
$exp system/manager inctype=complete file=990702.dmp
(2) "Incremental" incremental export backs up
data changed since the last backup. For example:
$exp system/manager inctype=incremental file=990702.dmp
(3) "Cumulative" incremental export (Cumulative)
The cumulative export method only exports the information that has changed in the database since the last "complete" export. For example:
$exp system/manager inctype=cumulative file=990702.dmp
The database administrator can schedule a backup schedule and use three different methods of data export to complete it reasonably and efficiently. For example, the database backup task can be arranged as follows:
· Monday: full export (A)
· Tuesday: incremental export (B)
· Wednesday: incremental export (C)
· Thursday: incremental export (D)
· Friday: cumulative Export (E)
· Saturday: Incremental export (F)
· Sunday: Incremental export (G)
If the database is accidentally damaged on Sunday, the database administrator can follow the following steps to restore the database:
Step 1: Use the command CREATE DATABASE regenerates the database structure;
Step 2: Create an additional loop segment that is large enough.
Step 3: Completely incremental import A:
$imp system./manager inctype= RECTORE FULL=Y FILE=A
Step 4: Cumulative incremental import E:
$imp system./manager inctype= RECTORE FULL=Y FILE =
Eth Step 5: Import the latest incremental F:
$imp system/manager inctype=RESTORE FULL=Y FILE=F
<2>Cold backup
Cold backup occurs when the database has been shut down normally. When it is shut down normally, it will provide us with a complete database. Cold backup is a way of copying critical files to another location. Cold backup is the fastest and most secure method for backing up Oracle information. The advantages of cold backup are:
· It is a very fast backup method (just copy the files)
· It is easy to archive (a simple copy is enough)
· It is easy to restore to a certain point in time (just copy the files back)
· It can be combined with archiving Methods are combined to restore the "latest state" of the database.
·Low maintenance, high security.
However, cold backup also has the following shortcomings:
·When used alone, it can only provide recovery to "a certain point in time".
·During the entire process of implementing backup, the database must be backed up and no other work can be performed. In other words, during the cold backup process, the database must be closed.
·If the disk space is limited, it can only be copied to other external storage devices such as tapes, and the speed will be very slow.
·Cannot be restored by table or by user.
If possible (mainly based on efficiency), the information should be backed up to disk, then start the database (so that users can work) and copy the backed up information to tape (while copying, the database can also work). The files that must be copied in the cold backup include:
·All data files
·All control files
·All online REDO LOG files
·Init.ora file (optional)
It is worth noting that the cold backup must be performed with the database closed. When the database is in When the database file system backup is open, it is invalid to perform a database file system backup. The
following is a complete example of doing a cold backup:
(1) Shut down the database $sqldba lmode=y
SQLDBA >connect internal;
SQLDBA >shutdown normal;
(2) Use the copy command to back up all Time files, redo log files, control files, initialization parameter files
SQLDBA >! cp < file > < backup directory >
(3) Restart the Oracle database
$sqldba lmode=y
SQLDBA >connect internal;
SQLDBA >startup;
<3>Hot backup
Hot backup is a method of backing up data using archivelog mode while the database is running. Therefore, if you have a cold backup from last night and today's hot backup file, you can use these data to restore more information when a problem occurs. Hot backup requires the database to operate in Archivelog mode and requires a large amount of archive space. Once the database is running in the archivelog state, a backup can be made. The hot backup command file consists of three parts:
1. Data files are backed up table space by table space.
(1) Set the table space to the backup state
(2) Back up the data files of the table space
(3) Restore the table space to the normal state
2. Back up archived log files.
(1) Temporarily stop the archive process
(2) Log files in the archive redo log target directory
(3) Restart the archive process
(4) Back up the archived redo log files
3. Use the alter database backup controlfile command to back up copy files.
The advantages of hot backup are:
· It can be backed up at the table space or data file level, and the backup time is short.
·The database can still be used during backup.
·Achieving second-level recovery (recovery to a certain point in time).
·Can restore almost all database entities.
·Recovery is fast and in most cases occurs while the database is still working.
The shortcomings of hot backup are:
·Cannot make mistakes, otherwise the consequences will be serious.
·If the hot backup is unsuccessful, the results cannot be used for point-in-time recovery.
·Because it is difficult to maintain, special care must be taken and "ending in failure" is not allowed.
(2) Another hidden danger from the inside - user management and password issues
here. In fact, as a database administrator, I know very well that the Oracle database itself uses many methods to enhance the security of the database. It is often seen that There are passwords, roles, permissions, etc. So let’s start with the simplest DBSNMP:
If the Oracle database adopts a typical installation, a user called DBSNMP is automatically created. This user is responsible for running the Intelligent Agent (Intelligent Agent) of the Oracle system. The default password of this user is also " DBSNMP". If you forget to change the user's password, anyone can access the database system through this user. Now let's take a look at what permissions and roles this user has, and then analyze the damage this user may cause to the database system.
Start the SQL/PLUS program and log in as this user:
SQL> select * from session_privs;
CREATE SESSION
ALTER SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE CLUSTER
CREATE SYNONYM
CREATE PUBLIC SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE TRIGGER
ANALYZE ANY
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE
|
You can see that this user is not a SYS or SYSTEM administrative user. However, it has two system-level permissions: UNLIMITED TABLESPACE and CREATE PUBLIC SYNONYM.
When you see these two permissions, you should immediately think that these are security risks, especially UNLIMITED TABLESPACE, which is one of the attack points that destroys the database system. If you still think that even if someone uses this unmodified password to log in to the database, there will be no loss, I have to remind you: this user has UNLIMITED TABLESPACE system permissions, and it can write a small script. Then maliciously fill the system with junk data, so that the database system cannot run and will directly lead to the final paralysis. At present, many database systems require 24/7 operation. If the system is filled with junk data, then by the time the database system is restored, irreparable losses may have been caused.
But besides DBSNMP, there are many other users, what should I do? Let us first take a look at the user management problems currently common in Oracle databases:
(1) Excessive permissions: General users who program and browse the ORACLE database often have DBA (database administrator permissions) and can make any modifications to the database system. or delete.
(2) Poor security: The default storage location of many ORACLE users is in the system table space. This not only affects the normal operation of the system, but also affects the data information of different users, makes them transparent and has poor confidentiality. As data continues to be added, it is possible for the entire database system to collapse.
(3) Passwords are regular: The bad habit of consistent user names and passwords formed in the early days of ORACLE debugging remains to this day; the passwords of system users SYS and SYSTEM are also known to everyone.
Knowing these common "problems", what should we do? Here are some of my suggestions:
(1) ORACLE DBA (database administrator) specifications
·The ORACLE user password under the SUN Solaris operating system should be kept strictly confidential and the password should never be set to ORACLE; a dedicated database administrator should be designated to change it regularly.
·The SYS and SYSTEM system administrator user passwords created by ORACLE initialization should be changed from the original MANAGER to other strings that are not easy to remember.
·The management port of ORACLE WEB SERVER has the ability for DBA to browse the database. Therefore, the password of its administrator ADMIN should also be kept secret. The password should not be set to MANAGER; and a dedicated database administrator should be designated to change it regularly.
·ORACLE DBA is best managed using a window-based interface on the SUN SPARC server console. The premise is that the ORACLE user starts the server, and then enters SVRMGRM in the window command line, which starts the ORACLE SERVER MANAGER menu management; after logging in with the SYSDBA identity, you can do database system maintenance work (2) SQL*PLUS programming
users Specification
·Specification of storage structure.
Considering that SQL*PLUS programming can meet the diverse application needs of various industries, companies, and departments, our SQL*PLUS programming users should also standardize in this direction: different types of applications must There are different users; different types of applications must have different storage locations, including the creation and planning of physical files, default table spaces, and temporary table spaces: When preparing to write a certain large-scale (from ORACLE data volume and user-oriented volume When considering an application, you should first create a logical storage location - a table space, and define the storage path of the physical files and the size of the hard disk occupied.
①. The default storage path of physical files is under /oracle_home/dbs. Use the UNIX command df -k on the command line to check the usage of hard disk resource partitions. If the oracle_home usage rate reaches more than 90‰, and there are one or more relatively free hard disk resource partitions that can be used, we'd better change the default storage path of the physical files to the relatively free hard disk resource partition path. Under this path, we can plan the storage of resource physical files like this:
xxx table space
xxx industry/xxx company/xxx department/xxx service.dbf
DEMO table space
default_datafile_home1/col /elec/sys4/demo1.dbf
default_datafile_home1/col /elec/ sys4/demo2.dbfCompany
system four simulation demonstration system physical file
HUMAN table space
default_datafile_home1/col/elec/human/human.dbfCompany
personnel department personnel management system physical file
BOOK table space
default_datafile_home1/col/elec/book/
book.dbfcompany Data room library management system physical file
QUESTION table space
default_datafile_home1/col/elec/client/question.dbfCompany
customer service department question library system physical file
PC table space
default_datafile_home1/col/chaoxun/client/pc.dbf
The physical files of the company’s PC after-sales service system
... table space
default_datafile_home2/…………………
and so on
. Description: where default_datafile_home1 refers to oracle_home/dbs; default_datafile_home2 refers to the relatively free hard disk resource partition path.
②. The size of the physical file is determined according to the amount of data, data objects, and program packages of the application system. Generally used for small systems that simulate demonstrations, the initial physical file in the table space is 2M to meet the requirements. If the amount of information is full, physical files can be added to expand the table space (the size of each expansion can also be tentatively set to 2M); generally The actual running application system can appropriately increase the initial physical file size of the table space, but do not allocate too large a time (because it is not easy to recycle space, but it is easy to expand the space). This also needs to be analyzed based on the specific situation: the amount of information is large, and it takes a long time. For applications that save time, if conditions permit, the table space can be as large as hundreds of MB or even GB; for applications with small amounts of information and frequent short-term refreshes, the table space can be controlled below 2 MB.
③. The name of the table space should use English characters or character abbreviations similar to those used in the system. The name of one or more physical files corresponding to the table space should also be relevant. If different users are in different default table spaces, the stored information cannot access each other. This is much more secure than storing all user information in the system table space. If a user is created using the ORACLE WEB SERVER management port, the default and temporary table spaces must be system table spaces. The DBA must remember to change the user's default table space. Temporary table spaces store temporary data segments and handle some intermediate operations such as sorting and merging. They can be placed in specially created table spaces according to actual application requirements; if the system table space is large, they can also be placed in the system table space. It is best to store data indexes created by users in different table spaces separately from data files to reduce data contention and improve response speed.