先日セキュリティキャンプ2022全国大会に参加したので、Webセキュリティクラスの応募課題を公開したいと思います。
そもそもセキュリティキャンプとは
セキュリティ・キャンプとは、日本における将来の高度IT人材となり得る優れた人材の発掘と育成を目的とした独立行政法人情報処理推進機構(IPA)の事業の一つです。
現代においては、情報セキュリティの脅威は高まる一方です。
本事業では、セキュリティ分野に興味を持ち、将来同分野で活躍したいという意志をもった若者に対して、高度な情報セキュリティ技術の習得機会を提供しています。また、モラルや法律遵守の意識、セキュリティ意識、職業意識、自立的な学習意識についても向上のための機会を提供しています。
本事業は、2004年度のスタート以来、2021年度のセキュリティ・キャンプまでで計989名の将来が有望なIT・情報セキュリティ人材を輩出しています。セキュリティ業界はもとより各方面から、高度な情報人材育成に有益なイベントとして高く評価されています。
引用: https://www.ipa.go.jp/jinzai/camp/2022/zenkoku2022_about.html
事前課題
Q.1（応募のモチベーションについて）
「Webセキュリティクラス」の講義のうち、特に受講したいと思う講義（複数可）に関して、その講義で「どのようなことを・なぜ学びたいか」を教えてください。とりわけ「なぜ学びたいか」の部分に関連して、いま応募を考えているあなたが感じておられる課題意識や、あなたの関心領域が伝わってくるような解答を歓迎します。
■ A.1
・作って学ぶ、Webブラウザ
私はユーザーとしても開発者としても普段から利用しているWebブラウザについての基礎・仕組みだけでなく、Webブラウザに関連する発生した際に被害が大きいまたは被害数が多い攻撃手法について知りたいためWebブラウザの開発を通してそれらを学びたいと思っている。
前者のWebブラウザの基礎・仕組みについて学びたい理由については3点あり、1点目は何事も基礎や仕組みを学ぶことで応用が効くからだ。特にフロントエンドについてはフレームワークなどのツールの流行り廃りが早いので普遍である仕組みを学ぶ意義は非常に大きいと考える。2点目はWebブラウザは便利なツールである一方で基礎や仕組みを知らなくても利用することができるため、エラーが発生した際にアプリケーションのロジックの問題なのかブラウザの仕組み上の問題なのか切り分けができないためそのような状況に対処するためにWebブラウザの基礎や仕組みを学びたい。3点目についてはHTML/CSSについて学び始めた際、Webブラウザの仕組みについて気になったのでレンダリング手順(DOMツリーの作成→CSSOMツリーの作成→DOMツリーとCSSOMツリーの結合→表示対象の大きさを相対的な大きさから絶対的な大きさに変換→表示)について学んだが、それ以上のことは他の興味のある分野について勉強をしていたら時間の確保ができず学ぶことができていなかったので、この機会に学びたいと思ったからだ。
Webブラウザに関連する発生した際に被害が大きいまたは被害数が多い攻撃手法について学びたい理由については、私はブラウザのセキュリティに関する基礎的な部分の知識しか持っておらず、もっとセキュリティに関する知識を身につけたいからだ。現在私はWebアプリケーションの機能の実装はできるようになったので次のステップとして高品質なものを提供できるようになりたいと考えている。そして、その高品質なWebアプリケーションの要素の一つとして脆弱性を持たないこと、脆弱性が見つかった際に仕組みを理解し対処することができることが挙げられるので目標を達成するために上記のことを学びたいと考えている。
Webブラウザ開発の体験を通して以上のことを学ぶことができると考えているためこの講義をぜひ受講したいと考えている。
・マイクロサービス/分散モノリス的アーキテクチャへの攻撃手法
マイクロサービス/分散モノリス的アーキテクチャを採用したプロダクトの開発・運用をするにあたって高頻度で発生する問題に対する攻撃手法やその対策方法、特に認証認可まわりの問題について学びたい。
私はインターンシップでの就業経験等からモノリスアーキテクチャにおけるセキュリティについて基礎的な部分は網羅的に理解することはできた。一方で、私は現在マイクロサービスに興味があるのでマイクロサービスを採用したWebアプリケーションを個人で開発中であるが、モノリスアーキテクチャと比較すると新しい技術であるマイクロサービスを用いて開発を進めるにあたりセキュリティ周りがわからず、特にアクセスに対して各サービスでの認証認可周りをどう管理・実装すべきか悩んでおり、どのような点に注意をして実装していくべきか知るために本講義を受講したい。例えば、あるアクセスに対しては本来アクセスすることができないサービスに対して別のサービスを経由するとアクセスすることができてしまう問題が発生するのではないか危惧しているとともにこの問題の解決策もわからないのでこのような問題の解決策を知りたいと思っている。
Q.2（これまでの経験について）
以下の経験について、差し支えのない範囲でできるだけ具体的に教えてください:
(1) Web アプリケーションの設計・開発経験（※ どんな些細なものでも構いません）
(2) 一般のプログラミングの経験（※ 使ったことのある言語や、その用途などを教えてください。レイヤは問いません）
(3) コンテナ技術の利用経験
(4) CI/CD 環境のセットアップ・利用経験
なお、この問は「この応募課題を提出する時点での経験」を問うものです。この応募課題を見た時点での経験はなくても構いませんし、この応募課題の記入にあわせての学習を歓迎します。
■ A.2
(1)
就業型インターン
- 株式会社クインテット
- HTML, CSS / Bootstrap, JavaScript / jQueryを用いたWebフロントエンド開発
- PHP / CakePHP2, MySQL(DB設計含む)を用いたWebバックエンド開発
- 株式会社var
- Go, GraphQL, MySQLを用いたWebバックエンド開発
(0から開発したのでファイルなどのアーキテクチャやスキーマの設計含む) - Python3 / Django, MySQLを用いたWebバックエンド開発
(0から開発したのでファイルなどのアーキテクチャやエンドポイント、DBの設計含む) - Goを用いたWebバックエンド開発 (API設計含む)
- TypeScript / Reactを用いたWebフロントエンド開発
- Go, GraphQL, MySQLを用いたWebバックエンド開発
- 株式会社JX通信社
- TypeScript / Nextを用いたWebフロントエンド開発
- Python3 / Djangoを用いたWebバックエンド開発
ハッカソン形式のインターン
- jig.jp
- JavaScript / jQueryを用いたWebフロントエンド開発
- JavaScript / Denoを用いたWebバックエンド開発 (API設計含む)
その他
- 大学の授業にてRuby / Ruby on Rails, SQLiteを用いたWebアプリケーション開発
(エンドポイント、DBの設計含む) - 個人開発にてGo, GraphQL, gRPC, MySQLを用いたWebバックエンド開発
(ファイルのアーキテクチャ、スキーマ、DB設計含む) - 個人開発にてPython3 / Django, MySQL, JavaScript / jQueryを用いたWebアプリケーション開発
(エンドポイント、DBの設計含む) - サークルでの開発にてPython3 / Django, MySQLを用いたWebバックエンド開発
(2)
- Python3
- Webバックエンド開発 (Django)
- デスクトップアプリ開発 (tkinter)
- 競技プログラミング
- ゲーム開発 (pyxel)
- データ分析 (numpy, pandas, matplotlib)
- PHP
- Webバックエンド開発 (CakePHP)
- JavaScript / TypeScript
- Webフロントエンド開発
- Webバックエンド開発
- C
- 高専の授業にて使用
- C#
- ゲーム開発
- Go
- Webバックエンド開発
- 徳山高専独自のアセンブラ / 機械語
- 高専の授業にて使用
- Java
- 高専の授業にて使用
- ゲーム開発
- Ruby
- 大学の授業にて使用
- Webバックエンド開発
(3)
- 就業型インターンや個人開発、サークルでの開発においてDocker・docker-composeの利用経験あり
- Dockerを用いて商用環境との差分を無くした
(4)
- CI/CDのセットアップをしたことはないが、デプロイ先の環境に応じて環境変数を変更したい要望があった際、稼働中のCI/CDの設定を変更した経験あり
- 就業型インターンにてGitHub ActionsやGitLab CI/CDなどのツールを利用した経験あり
- 就業型インターンにてデプロイ先によって読み込むenvファイルを変更する修正を行った経験あり
Q.3（あなたの感心・興味について）
Web に関連するサービス・プロダクトを作って提供することに関連する技術で、いまあなたが興味を持っているものがあれば、それについて自由に説明してください。少しでも Web との関連性がある技術であれば、それがハードウェア領域に近いものでも、ソフトウェア領域に近いものでも構いません。
■ A.3
【gRPC】
Web に関連するサービス・プロダクトを作って提供することに関連する技術として現在私が興味のある技術はgRPCである。理由としては既存のHTTP1.1やJSON形式を用いたRESTなどの通信において発生する様々な問題を解決する技術であると感じたからだ。
gRPCとはGoogleが開発したRPCフレームワークでクライアントとサーバー間の通信プロトコルである。また、大きな特徴としては主にProtocol BuffersとHTTP2を利用している点でこれによりそれぞれのメリットを享受できている。ちなみにgRPCのgはGoogleではなくバージョンによって異なる意味を持っている。また、gRPCのキャラクターはGolden RetrieverのPanCakes。
https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md
既存の技術の問題点として、どのエンドポイントとどのエンドポイントがどのような通信を行なっているのか把握しにくいことが挙げられる。原因として、マイクロサービスの普及や様々なクライアントデバイス(Web, iOS, Androidなど)に対応する必要が出てきたことが考えられる。そこで、Protocol Buffersを使用すると通信を行う際のデータの内容をファイルに記述してそれをもとにコード生成を行うのでファイルに記述した内容と実環境で動いている通信を同期させることができ、データを定義したファイルと通信内容が同期しているので、データを定義したファイルをそのままドキュメントとして利用することができる。また、通信内容を定義する際は型を指定するためJSON形式のように型が欠損して予測で型を割り当てることはないので保守性を担保することができる。さらに、コマンド一つでデータを定義したファイルからある程度コードを自動生成することができるのでその点も非常に使いやすい。
HTTP2を利用するメリットについて、まずProtocol Buffersにも言えることだがバイナリベースでの通信なのでHTTP1.1のようなテキストベースの通信と比較するとデータ量を削減することができる。また、ヘッダ圧縮をすることができる規格により接続の初回以降はオーバヘッドを削減することができ、これも通信時のデータ量を削減することができる。そして、この2点からデータ量を削減することができたことでHTTP1.1の時よりも効率的な双方通信をすることができるようになった。最後にサーバ側のメリットとしては、1つのTCP接続に対して複数の仮想的な接続が作成されるのでサーバの負荷削減につながる。
gRPCのような他サービスへアクセスするための技術としてはRESTやGraqhQLなどが挙げられるが、それらを実装する際はライブラリの特性上通信が終了したら行う処理を記述するなど、通信を意識した実装を行う必要がある。一方で、gRPCの場合gRPCはRPCをベースに作られた技術であるため他サービスを関数のように呼び出すことが可能なので通信を意識することなく一機能のような扱いで実装することができる。
Q.4（Web に関する脆弱性・攻撃技術の検証 1）
Cross-Site Request Forgery (CSRF) とは何か、現代の Web ブラウザ・Web アプリケーションフレームワークが備える仕組みを深く考慮しながら、自分の言葉で説明してください。なお、関連する仕様や実際の実装例の挙動を論拠にする場合は、ぜひその出典を明記してください。
■ A.4
概要
攻撃の概要としては攻撃者が用意したリンクやサイトにアクセスすることをきっかけにして、被害者がログイン済みの標的のサービスに対して不適切なリクエストを送信する攻撃である。また、よく行われる攻撃方法としてはhiddenを設定したフォームを配置するとともにページを読み込む際に実行するonloadにフォーム送信用の関数を設定することで対象のリンクにアクセスさせる方法がある。他には一見わかりにくいimageタグのリンクに攻撃用のリンクが設定されることもある。このように設定されるとブラウザはhtmlファイルからレンダリングをするために画像ファイルと思われるリンクを読み込んでしまうため、ユーザーは気づかないうちに攻撃用のリンクにアクセスしてしまう。
仕組み
Webアプリケーションはクッキーに保管されたJWTやセッションIDから誰がアクセスしてきたかを判断し、エンドポイントや入力値に対する処理を行なっているだけで、本当にJWTやセッションIDに書かれたユーザー自身が意図してアクセスしたかは判断できない。そのため、CSRF攻撃を行う攻撃者はこの仕組みを利用して、攻撃対象に攻撃用リンクにアクセスさせることで攻撃対象のJWTやセッションIDを使用してなりすましを行なっている。
脆弱性が生まれる原因としては以下の二つが挙げられる。
- フォームのactionにはどのドメインのURLでも指定できる
- クッキーに保管されたセッションIDは対象のサイトに自動的に送信される
1.については罠などのサイトからでも攻撃対象のサイトにリクエストを送信することができるということである。また、2.については罠経由のリクエストに対してもJWTやセッションIDなどを持つクッキーを送信するので認証された状態で攻撃リクエストが送信されるということである。
対策
代表的な対策としてはCSRFトークンの埋め込みである。例えば、PythonのWebフレームワークであるDjangoではformを作成する際にcsrf_tokenという処理を記述する必要があり、この処理はランダムな文字列を生成することでリクエストを受け付けた際ランダムな文字列が適当であるかを判断することで適切なリクエストかどうかを判断している。https://docs.djangoproject.com/en/4.0/ref/csrf/
他の対策としてはユーザーが意図して処理を行なったかを判断するためにユーザーにパスワードを入力してもらう方法や、ページ遷移順が決まっているサービスならページ遷移順に沿わないページからのアクセスは不審であるためページ遷移順が正しいかリファラをもとに確認する方法などもある。また、直接的な対策ではないが被害が発生した際にいち早く気づくために重要な処理を実行した際はユーザーにメールを送信する処理を実装することや意図なく長くすると攻撃可能時間が長くなってしまうのでクッキーのexpire時間を必要最低限の長さに設定することなどが挙げられる。
Q.7（Web サービス・プロダクト開発に関する仕組みの検討）
あなたがチームで Web アプリケーションを開発していくための組織やプロセス、そしてそれを支える技術基盤の設計と実装を任されたとします。その際にセキュリティ上考慮すべきだと思う点を可能な限り列挙し、理由とともに説明してください。
解答の際には、一からすべて自分で考えるのではなく、OWASP や NIST 等が提示している何らかの文書（例: OWASP SAMM や NIST SSDF 等）を参考にしても構いません。また、気をつけるべき点を考えるだけではなく、具体的に何かを構築してみた場合は、ぜひそれも本設問の回答として含めてください。
■ A.7
- GitHubなどのサービスでバージョン管理を行う際に公開設定をprivateにする
仮にリポジトリをpublicにしていると開発に関わっていない悪意ある第三者がコードを閲覧しどこにどのような脆弱性があるか調べることができ、その脆弱性を利用した攻撃をされてしまう可能性がある。また、タスクをissueで管理している場合、バグの報告など内容によってはそこからも脆弱性を発見されてしまう可能性がある。 - 脆弱性診断やペネトレーションテストの実施
脆弱性診断を実施することでシステムの脆弱性を網羅的に調べることができる。また、実際にありそうなシナリオをもとに攻撃を行うペネトレーションテストを行うことで、より現実的に発生しうる攻撃を知ることができる。 - ファイアウォール・WAFの設置
ファイアウォールやWAFを設置することで、インバウンド方向の不正なアクセスを遮断することができる。また、仮に不正なアクセスが内部のネットワークに侵入した際に情報が外部に出ないようにするためにアウトバンド方向の通信も制限することができる。 - 不要なサーバーは公開設定にしない
例えば、サービス間でのやり取りの結果をBFFに渡してそこからフロントへレスポンスを返すような構成で運用していたとすると、フロントから見ると結果を返すBFFしか必要がないため他のサービスも公開設定にしてしまうと悪意ある攻撃者が侵入する可能性のある経路が増えてしまい、リスクになってしまう。また、データベースもフロントからは必要ないため公開設定にしてしまうと情報漏洩につながってしまう。 - VPN
開発サーバーや商用のサーバー等にアクセスをする際どのような経路でアクセスするかわからないため通信を盗聴されてしまうなどのリスクがある。しかし、適切なVPNを使用することでトンネリング、暗号化、認証の機能を享受することができ、盗聴等の情報漏洩リスクを軽減することができる。 - セキュリティ教育
セキュリティエンジニア等が必死にインシデントが発生しないような設定を行っても、セキュリティの知識がない人が商用のリポジトリを自分のアカウントで勝手に公開指定しまうなど知らず知らずのうちにインシデントにつながる行動をしてしまう可能性があるので定期的にセキュリティに関する教育を行うことで、インシデント発生のリスクを軽減することができる。 - パスワード管理マネージャの使用
人間が覚えることができるものの数には限りがあるため、誕生日や名前など覚えやすい情報を含むパスワードを使いまわしている状況は多々ある。ただ、これだとパスワードが推測されてしまったり、どこかでパスワードが漏洩した際に芋づる式に他サービスの利用に影響が出てしまう可能性があるので、強固なパスワードを自動生成・管理することができるパスワード管理マネージャを導入することで以上のようなリスクを軽減することができる。 - シングルサインオンの利用
利用するサービスが多段階認証を実装していない場合でもSSO側で多段階認証を利用する設定を行えば、利用するサービスでも多段階認証を利用することができ、セキュリティの強化につながる。また、ユーザーがPCを紛失してしまうなど何か問題が発生した際に、SSOを利用していない場合だと利用しているそれぞれのサービスのアカウントを停止する必要があるため、手間や時間がかかり漏れが発生する場合もあるが、SSOを利用しているとSSOのアカウント一つを停止するだけで済むので手間や時間がかからず漏れが発生する恐れもないためセキュリティ強化につながる。 - 二要素認証
認証を行う際に必要なものとしては大きく分けて三つの要素である知識・所有・生体がある。二要素認証はこれらの要素の内二つを使用するためセキュリティの強化につながる。例えば、私が使用しているSony銀行のアプリの場合だとまず知識要素であるIDとパスワードの入力が求められ、次に所有要素であるデビットカードの製造番号の入力が求められる。このようにすることで仮にパスワードが漏洩してしまった場合でもアプリへのログインにはデビッドカードが必要になるためリスクは軽減される。 - DBやディスクの暗号化
DBやディスクの暗号化を行わない場合、サーバーに不正にアクセスされ管理者権限を取得されてしまうとDBにログインすることなくデータファイルやディスクに直接参照されることで情報漏洩につながってしまうため、このような問題の対策としてDBやディスクの暗号化を行う必要がある。 - クラウドや管理ページなどの権限はユーザーごとに管理する(最小権限の原則)
ユーザーの業務に必要な権限以外の権限も与えてしまうと、不正ログイン等によりアカウントを乗っ取られた際に権限が多いことで攻撃による被害が拡大してしまうため、必要最低限の権限のみをユーザーに与えることでインシデントが発生した際の被害の拡大を防ぐことにつながる。 - PCの貸出
私物のPCで作業してしまうと、セキュリティソフトが入っていなかったりセキュリティソフトの設定が各個人異なることで安全性を担保することができないので、セキュリティソフトの導入等必要な設定をおこなったPCを貸出することである程度の安全性を担保することができる。 - 遠隔操作を行う際はtelnetは使用せずsshを使用する
telnetは通信の暗号化がされないため、telnetを使用してしまうと通信を盗聴されてしまう可能性がある。一方で、sshは通信が暗号化されるので盗聴されても中身を解読できないのでセキュリティの安全性を担保することができる。 - 実績などをみて信頼のおける認証局から証明書を取得する
通信の安全性を確保するために通信相手を保証する信頼性の高い証明書を利用する必要がある。そのためにも今までの実績等を見てその認証局が信頼性の高い証明書を発行することができる信頼された認証局なのか判断をする必要がある。 - クラウドサービスを使用するときに費用を使いすぎた際にアラートが飛ぶ設定を行う
AWSのEC2のような利用時間に対して費用が請求されるサービスではなく、Lambdaのような実行回数に対して費用が請求されるサービスに対してDDoS攻撃のような大量のアクセスを行う攻撃を受けてしまうと多額の請求がされてしまうEDoS攻撃が発生してしまう。そこで、ある一定の利用料を超えるとアラートが飛ぶような設定をすることでEDoS攻撃による被害を最小限に抑えることができる。 - サーバー監視ツールの導入
サーバー監視ツールを導入し問題が発生した際にアラートが飛ぶ設定を行っていたとすると、例えばDDoS攻撃によりサーバーがダウンしてもアラートが飛んだことでサーバーがダウンしたことに気づくことができ素早く復旧することができる。 - 実装する際に、必要な情報をログに残す
インシデントが発生した際にログは大きな手がかりになるので、後から読みやすい形で情報の分類や具体的な記述の内容を設定することで、より解析者がインシデントの原因究明を行いやすくなる。 - テストを書く
テストを書くことで確認するべき項目を、機械的に問題があるかどうかを判断することができる。また、テストを書いておくことでその後テストの対象となる部分を改修したとしても既存のテストを実行することで既存の機能が失われていないかどうかの確認をすることができ、バグの発生を抑制することができる。 - CI/CDでテストを実行して問題ないかの確認を行い、デプロイする
テストが通らない場合でもCI/CDの設定や手作業でのデプロイ作業を行うと問題のある機能でもリリースできてしまうため、開発体制としてデプロイ作業はCI/CDによる自動化を前提としてCI/CD実行時に全てのテストが通らないとデプロイできないように設定を記述することで必ず全てのテストを確認してからデプロイできるようにすることができ、バグの発生を抑制することができる。 - 使用するライブラリに致命的な脆弱性がないかを調査する
機能だけみてライブラリを導入してしまうと致命的な脆弱性や開発者が意図的に含めた悪意あるスクリプトの影響を受けてしまうため、使用を検討しているライブラリに対して本当に導入しても問題ないかを調査することでリスクを軽減することができる。 - DevSecOpsの導入
要件定義や設計、実装などの各工程で脆弱性が発生してしまうリスクを軽減するために、各工程に応じた対策をプロセスに組み込むことで開発スピードを損なうことなくセキュリティ対策を行うことができる。
Q.8（新しい領域に関する調査）
Sigstore プロジェクト (https://sigstore.dev) について、それがどのような課題を、概ねどのような方法で解決することを目指しているのかを簡潔に説明してください。可能であればそれに加えて、以下のような調査・吟味を行い、その結果について論じてください。詳細な解答を歓迎します。
(1) どのような技術的な仕組み・理論に裏付けられているのか
(2) 実社会で実際に運用可能そうなものなのか
■ A.8
Sigstoreプロジェクトとは全てのソフトウェアはどこから来たのかわからないということは開発したサービスの完全性に対するリスクを発見することが難しいという課題をデジタル署名とコンポーネントのチェック方法を自動化し、ソフトウェアをソースに遡ってより安全に管理するための仕組みを実現することで課題の解決を目指している。これにより、サービスがOSSに依存している場合、将来の統合によりソースコードがどこにあっても真正性を簡単に確認することができるようになる。
また、sigstoreは単体でも使用することができるCosign（コンテナへの署名、検証、保管）、Fulcio（ルート認証局）、Rekor (透明性ログ)、OpenID Connect (認証手段)という四つのOSSを組み合わせて実現している。その仕組みとはまず利用者が開発者であるかを証明するためにメールアドレスを調べるOpenID Connectを使用する。そして、利用者が誰であるかを確認するためにFulcioを使ってsigstoreはルート認証局(CA)に証明書を要求する。Fulcioはタイムスタンプ付きの証明書を発行し利用者がサインインしていること、そしてそれが利用者であることを示す方法を提供する。また、sigstoreが利用者の秘密鍵を取得することはなく、Cosignが作成する公開鍵は利用者の証明書にバインドされ、署名の詳細はsigstoreのトラストルートに保存される。その後、利用者の証明書はsigstoreに戻り、sigstoreは鍵を交換し利用者の身元を証明したのち全てに署名する。署名には、ハッシュ値、公開鍵、署名の内容、タイムスタンプが含まれる。これはすべてRekorの透明性ログにアップロードされるので利用者が公開したものが本物であるために必要なすべてのチェックを通過したことを誰でもチェックすることができる。
最後に、いくつかの課題を解決することができればSigstoreプロジェクトは実社会でも運用可能であると考える。まず、導入障壁の低さだ。これについてはSigstoreプロジェクトのサイト内で上記のプロセスの自動化を行ったと記述してあったため解決したまたは運用に足るレベルで自動化されていると考えられる。次に、知名度の向上である。このプロジェクトを利用してサービスの安全性を確認するにはサービスが使用しているOSSもこのプロジェクトを利用している必要があるため少なくとも有名なOSSには利用されている必要があるため知名度の向上が必須である。こちらについてはGitHubなどOSS開発・公開のプラットフォームと協力して広報していくことで解決すると考えられる。
最後に
セキュリティキャンプに参加していなかったら触れることがなかった知識や経験を得ることができたので、少しでも興味がある人は参加してみてください！また、セキュリティキャンプ参加後に読み返すと内容的にイマイチな箇所が多々ありますが、応募しようと思った方が課題をこなす際に少しでも参考になればと思います。