1 / 36

Milestone 2

Milestone 2. Workshop in Information Security – Distributed Databases Project. By: Yosi Barad , Ainat Chervin and Ilia Oshmiansky. Project web site: http://infosecdd.yolasite.com. Access Control Security vs. Performance. Milestone 2:. Our Plan:. 1. 2. 3. 4. Milestone 2:.

elan
Download Presentation

Milestone 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Milestone 2 Workshop in Information Security – Distributed Databases Project By: YosiBarad, AinatChervin and IliaOshmiansky Project web site: http://infosecdd.yolasite.com Access Control Security vs. Performance

  2. Milestone 2: Our Plan: 1 2 3 4

  3. Milestone 2: Our Plan: 5 6 7

  4. Milestone 2: Our Plan: 8 9 10

  5. Plan Step 1: • Steps: • Fully understand the Cassandra data structure • Cassandra terminology- • - A "Cell" is actually called a "Column" it is the lowest/smallest increment of data and is represented as a tuple (triplet) that contains a name, a value and a timestamp.

  6. Plan Step 1: -Next we have a "Column Family" which is a container for rows, and can be thought of as a table in a relational system. Each row in a column family can be referenced by its key.

  7. Plan Step 1: -Finally, a "Keyspace" is a container for column families. It's roughly the same as a schema or database that is, a logical collection of tables.

  8. Plan Step 1: • Understand the code flow of get and set operations. • The security logic is separate from the rest of the codeand has two main interfaces: • 1) Iauthenticator – responsible for authenticating the user that logs in. • 2) Iauthority – responsible for authorizing the access of an authenticated user to a specific resource. • It is possible to write our own code which implements these Interfaces.

  9. Plan Step 1: • The Initial code had the following classes: • "AllowAllAuthentication.java“ - implements Iauthenticator . "AllowAllAuthorization.java“ - implements Iauthority. • With some research we found: • "SimplelAuthentication.java" • "SimpleAuthorization.java” • That allow some simple user authentication and a basic ACL.

  10. Plan Step 1: • Some information about these classes: • use two additional configuration files: • password.properties – a list of users and their passwords. access.properties – contains a set of permissions.

  11. Plan Step 1: • There are several problems with this implementation: • Very inefficient • Need a lot of maintenance. • Despite these issues we still believed we should use this code as a starting point having full intentions to improve it.

  12. Write some initial code Plan Step 2: • The initial code we wrote: • Implemented the RowKey access control. • At this point we could limit the access of Read/Write to a specific Row within a ColumnFamily. • Keyspace1.Users.key1.<rw>=yosi

  13. Write some initial code Plan Step 2: • Implemented the Column access control. • Same as The RowKey access control, this time we went a level lower. • Keyspace1.Users.key1.column1<rw>=yosi

  14. Write some initial code Plan Step 2: • We set a new syntax to the Cassandra client: <column value>: [<user1,user2,...> <permission>] [...]. • For example: • Set Users['key1']['City'] = 'Haifa:scott,yosirw:Andrewro'; • This command does the following: • creates a new column named "City" with value "Haifa" in column family “Users“. • Writes the permissions to the access.control file in the correct format. • In the following example we will add the following two lines to the access.control file: • Keyspace1.Users.key1.City<rw>=scott,yosi • Keyspace1.Users.key1. City<ro>=Andrew

  15. Test our implementation using YCSB++ with basic configuration Plan Step 3: • We ran one basic test on it to get an idea of where we stand in terms of performance. • The results we got were terrifying (as expected): • An average of under 40 op/sec and it got lower the more tests we ran every new entry meant another line in the file that we need to scan. • Our next step was to improve the implementation so that it won't rely on configuration files.

  16. Try to implement several different solutions to be tested against each other Plan Step 4: • Our two implementations were: • 1) Writing the permissions to a file. • 2) Storing the permissions within the values of the columns in Cassandra.

  17. Storing the permissions within the values of the columns in Cassandra. Plan Step 5: • This stage included the following: • Parse the value returned from Cassandra. • Add a new "get" function to grab and separate the ACL from the actual value of a Column. • For example: • Yosi wants to run the following command - • This command will now work as following: • Get the value and check the ACL in the value • Perform the validation • Perform the actual insert.

  18. Story to be told - version 1 Milestone 2 • Try to implement several different solutions to be tested against each other יוסי הקפדן איליה הסקרן עינת המגניבה Access and modify VerySecretValue Won’t be able to access VerySecretValue VerySecretValue:Yosi,Ainatrw

  19. Story to be told – version 2 Milestone 2 • Try to implement several different solutions to be tested against each other יוסי הקפדן איליה הסקרן עינת המגניבה Access and modify VerySecretValue Access but not modify VerySecretValue VerySecretValue:Yosi,Ainatrw:Iliaro

  20. Demonstration Milestone 2

  21. Storing the permissions within the values of the columns in Cassandra. Plan Step 5: • In order to further enhance the performance: • We removed the "SimpleAuthority" related functions. • We changed the implementation of the "authorize" function in the SimpleAuthority class to read the ACL from the value within the Cassandra DB rather than from the access.Properties file.

  22. Run more advanced set-ups of YCSB++ (custom workloads) Plan Step 5: • To test our implementation we had to: • - Add ACL entries to the values YCSB sent to Cassandra • - Get YCSB to login to Cassandra with a user and password • This included the following steps: • -Compile YCSB (this was a challenge since this code has no documentation anywhere) • -Editthe YCSB code to connect to Cassandra with our user. • -Change the way YCSB generated values to fit our custom format (<val>:<users> <rw>:<users> <ro>). • -Recompileit with different number of ACL entries for our "increasing ACL" test. • Now we got much better results:

  23. Plan Step 5: Workload A: Update heavy workload - mix of 50/50 reads and writes.

  24. Plan Step 5: Workload B: Read mostly workload – This workload has a 95/5 reads/write mix

  25. Plan Step 5: Workload C: Read only - This workload is 100% read.

  26. Plan Step 5: Workload D: Read latest workload - In this workload, new records are inserted, and the most recently inserted records are the most popular.

  27. Plan Step 5: Workload F: Read-modify-write - In this workload, the client will read a record, modify it, and write back the changes.

  28. Compare the test results to the results of our initial tests Plan Step 5: • The current results aren't satisfying as they do not sit well with what was expected (we expected the throughput to decrease with each additional entry).

  29. Set up a more advanced configuration of Cassandra (consisting of several nodes) Plan Step 6: • We realized that we rather wait for a local HD allocation for running several Cassandra nodes because: • - A shared hard drive would be the bottleneck and won't increase the performance • - It is very hard to benchmark this remote storage. • - It is time consuming to set-up the clusters and if we'll get the local HD allocation we might spend more time on building this configuration again. • We sent a request to the system admin for local HD allocations so we could install Cassandra and test performance running on a local HD.

  30. Test the performance of the advanced configuration of Cassandra with and without the added Cell-level Security Plan Step 7: Once we will finish the more advanced set-up, we will be able to run both Cassandra implementations (with and without the added security) and thus get the desired results.

  31. Create a final version of the implementation based on the test results Plan Step 10: • We would like to further analyze the code and find ways to improve it (see plans for ahead). • Furthermore, we cannot rely on the tests we ran so far as they do not accurately assess the performance.

  32. Milestone 2 Progress Compared to Plan:

  33. Overall Milestone 2 We completed the goal of implementing cell-level ACL security, but there is still some work to be done in the performance testing and perhaps the code can be further improved.

  34. Plans for ahead Milestone 2 • Expand the Cassandra setup– • Upon receiving the local HD allocation we requested we can continue with the more advanced testing and create a setup consisting of several nodes/clusters. • Expand the tests, search for limiting factors- • We plan on expending our tests in several directions.

  35. Plans for ahead Milestone 2 • Evaluate how to further improve the implementation – • At this point we do not see any major issues in our implementation. Also, we will have to run better tests to understand the actual performance penalty of our implementation and perhaps need some guidance to see where we can improve. • Start analyzing security holes due to inconsistencies – • We need to figure out how to measure the inconsistencies using YCSB++ and assess the security threats that might arise from these inconsistencies.

  36. Questions? Milestone 2

More Related