Читать книгу Cyber Security and Network Security - Группа авторов - Страница 39

The server side application is developed using Python Django. Python version 3.x is recommended for development. Our application is developed using Python 3.8. The suggested required libraries and their versions are also provided in Table 1.1.

Table 1.1 Libraries and their versions

Cryptography	Encryption (like AES)
Django-dynamodb-sessions	For NoSQL
Dynamodb-json	DynamoDB Json
Boto3	AWS SDK for Python (Boto3) to create, configure, and manage AWS services

The EC2 that was set up during testing was a T2 instance of the Micro specifications with 1.0 GiB RAM and 1vCPU. The application was set up in the Linux environment, and a startup script was put in place so that it would spin up the application whenever the instance starts. The application took in responses in a form of Rest API calls, and thus, the server provisioned is set up under a security group with network ingress egress allowed on Port 80.

For secure shell connectivity to the server for maintenance and optimizing and security purposes, the SSH port is kept open in the security group. This enables the administrator to connect to the server instances over the public internet securely. RSA keys are also advised to be used for encrypted secure login.

In a public cloud service, the servers and the security groups can be set up inside a virtual private cloud within public subnets facilitating public facing servers within a secure sandboxed environment so that the whole operation runs securely. Whole setup can also be done using integrated platforms (platform as a service) such as infrastructure as a code such as cloud formation services. Figure 1.2 shows home or my profile page from manager’s point of view.

Figure 1.2 Home or my profile page from manager’s point of view.

In our proposed model, the managerial role in the organization is the administrator of the system suggested. The name of the roles in our proposed model may vary and can be changed according to the enterprise specifications, but the logic behind the operations is suggested to be kept the same. The manager has the highest access privilege than the other users in the system. Here, he/she can control document transactions and user managements monitoring and tracking the access granted to the respected users. From the Profile page of the manager, he/she can create or delete (CRUD) any announcements, and small synopsis of unread or latest communications are also viewed in the home page.

The data of the announcement, or the communications that are being sent, are sent in the JSON format by the client machines which are encrypted using DES encryption first and then AES over it. After going through the public internet and reaching the server endpoint, the encrypted data packet is decrypted. Further, the data is analyzed for infections or malware. If the data is found to be free of such things, then the JSON data is analyzed. If the content key in it contains the value “announcement”, then the data within is saved in the Announcement Table in the NoSQL database. Here, in our proposed model, we use DynamoDB because of its high scalability, serverless structure, and single-digit millisecond latency. Similarly, the “communications” would be saved over in the Communications table in the same database.

The proposed Json file structure would be like the following:

{

content: “announcement”,

data: [‘this is an array of string and objects’],

data-type: ‘text/html’

}

After clicking on the Logout button, the users are disconnected from the server and sent back to the Login page. No further actions can be carried out by that particular user’s identity unless he or she logs back in. Figure 1.3 shows home or my dashboard page from employee point of view.

Figure 1.3 Home or my dashboard page from employee point of view.

Here, it shows the profile of the employee in the organization from where he/she can view the profile, get necessary updates (i.e., from Announcements, Inbox), and perform the job. From the Home or My Dashboard page, employees see the announcements, small synopsis of unread or latest mail. On clicking over the object storage, it will be redirected to storage or bucket page. From the navigation dashboard, employees can go to any page (only eligible pages) according to their choice. Apart from all these, users can also logout from the page by clicking on the Logout button at bottom right of the page. For the users to store object-based files, the users are authenticated and the client side of the software verifies the file and compresses it after encrypting. Here, we use double layer security, i.e., for the first layer we have used the DES encryption, over that a second layer of encryption, i.e., AES is applied over it. Further, encrypted compressed objects are sent over the public internet and are in a S3 bucket through the REST API that is put in place. After a new object is created over in the primary S3 Bucket, a serverless lambda function gets invoked and the encrypted compressed file is decompressed and decrypted accordingly. Further, after a series of actions verifying the authenticity of the file sent, the file is compressed and stored in another S3 Bucket from where it would be retrieved when required. A life cycle policy is put in place where the older objects which are not required frequently are transferred to an economical tier, and the other much older objects are transferred over to glacier object storages for archival purposes. Figure 1.4 shows inbox page from manager’s point of view.

Figure 1.4 Inbox page from manager’s point of view.

Here, it shows the inbox page of the manager in the organization from where he or she can send mail within the organization. Just by entering the client id of the employee, the mail will be received to the employee’s inbox. It can contain any number of documents by attaching it with the storage bucket. Here, past mails or drafted mails can be edited, modified, and sent. If the manager wants to send the mail to the entire department, then it can also be done by tagging the entire department. All those details, i.e., data in transit and data in rest will be encrypted and safely stored in cloud such that no third party applications cannot take the data without the owners concerned [15]. Employees have the access to view the mails sent to them and reply to them. Figure 1.5 shows flowchart of inbox, and Figure 1.6 shows storage bucket from manager’s point of view.

Here it shows the Storage Bucket page of the manager in the organization. Manager can upload any data in the storage bucket and can share it easily within the organization. Employees can do their work by making a copy of the data and can submit it when they finish. When a manager needs to search any files he or she just needs to search by the file name or client id in the search field. Apart from that, the manager can also sort the table according to his or her own preference. Managers have the permission to view, create and delete the files of all the employees. Employees can only access the files or documents only for those they have been eligible for.

To save the files of the Storage Bucket, we have chosen Amazon S3 for our model. It is highly scalable and any amount of objects can be stored in it.

Figure 1.5 Flowchart of inbox.

Figure 1.6 Storage bucket from manager’s point of view.

Figure 1.7 Flowchart of storage bucket.

A log will be maintained for storage and deletion of objects in QLDB safely. Figure 1.7 shows flowchart of storage bucket, and Figure 1.8 shows Manage Employees page from manager point of view.

Here, it shows the Manage Employees page of the manager in the organization. The managers can add new employees, update employees, and delete employees in the organization. Apart from that, he or she can also add and manage enterprises. Manager can search employee details just by entering the employee id of the employee in the search field. Manager has full authority over the employee, i.e., if he or she wishes to suspend any employee from accessing the application, then he or she can do so. Employees cannot access the Manage Employees page from their end as, at every step, manager’s credentials will be checked before giving allowance inside the system.

Figure 1.8 Manage employees page from manager point of view.

In our proposed model, we have used NoSQL databases because they are highly scalable and large volumes of data can be stored without having any specific architecture. Editing on these databases is quite fast and easy. If development is made using modern agile methods, then relations database is not the right option as it slows you down, but in NoSQL databases, the level of preparation is not needed making work faster. Moreover, cloud-based storage requires data to be spread across multiple servers. A highly scalable database is required for such production and NoSQL databases perfectly fit in the case. Figure 1.9 shows flowchart of employee database, and Figure 1.10 shows announcement page from manager point of view.

Here, it shows the Announcement page of the manager in the organization. Here, the manager can view, edit, add, and delete announcements. The manager can send announcements to the entire department by entering the department id of them.

In our proposed model, we have selected NoSQL databases for storing the announcements. As it has no predefined schema, storing important announcements or deleting them later can be done with great ease. We have chosen multi-level encryption. We will use DES and AES encryption to encrypt the database before pushing it to QLDB. DES is a symmetric encryption algorithm converting data into block ciphers. It uses key sizes of 64 bits.

Figure 1.9 Flowchart of employee database.

Figure 1.10 Announcement page from manager point of view.

AES encryption is the most robust security protocol against hacking. It uses higher key sizes such as 128, 192, and 256 bits of encryption. It is one of the safest open source security solutions widely used commercially for encrypted data storage.

First, we will encrypt the data using DES and generate a key and further encrypt it using AES providing a second level of encryption.

The encrypted files are stored in QLDB (Quantum Ledger Database), a ledger database holding all records. These files can be decrypted again and viewed in QLDB if needed. We have chosen QLDB for our proposed model as it is a NoSQL database, with some additional features. Figure 1.11 shows flowchart of creating announcement, and Figure 1.12 shows group access control modifier by manager.

In our architecture, a highly strict policy for least access privilege model is followed to ensure that no user gets access to resources more than he is supposed to. The Group Access Control Modifier thus provides that opportunity for the immediate senior managers assigned to the users to access their control privileges. This ensures that no information flows in and out of the system that is not asked to be retrieved by an authenticated user with necessary access. The Group Access Control Modifier is the GUI of a backend architecture with a JSON file containing the detailed Access Policy for specific users. Whenever the Access Policies are changed over in the GUI, the contemporary JSON file updates itself accordingly.

Figure 1.11 Flowchart of creating announcement.

Figure 1.12 Group access control modifier by manager.