  |
はてなキーワード: sqlインジェクションとは
しったかが適当こいてもこうはならんだろってくらいはちゃめちゃ
最高
いいよいいよ
「つまりユーザの入力をそのままどこかに出力したら駄目なんだな」
ってことをわかってくれてればいいんだ
SQLインジェクションとクロスサイトスクリプティングを取り違えてたっていいよ
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
32 風吹けば名無し＠転載禁止 [sage] 2014/11/25(火) 04:07:46 ( tor-elpresidente.piraten-nds.de )
使えなくは無いけども当職は使わないナリ
kaliかtailsをCDに焼いた方が便利ですを。win系のパスクラならophcrackがオススメナリ
守り方だけど鯖建てたい初心者はhackmeで検索してSQLインジェクションとXSS辺りの初歩を学ぶと良いナリ
バッファオーバフローはアップデートと設定さえ、やっとけば0dayで無い限りやられることは無いと思うナリ
win系とかの簡易ウイルス発見テクは「タスクマネージャが出ない」「隠しフォルダが強制非表示になる」
「サービス、スタートアップ、タスクスケジューラに不審なexeが登録してある」「USBを挿した時autorun.infを上書きしようとする」等々のパターンが多いナリ
とりあえず常駐プロセスとサービスがどこの会社のどのソフトか理解しておくことも早期発見に繋がるので大切ナリ
防御ソフトとしてはpeerblock、sandboxie、privoxy、EMET、DNSCrypt、comodo firewall辺りと適当なウイルス対策ソフトナリ
ブラウザはfirefoxでアドオンはadblock edge、cookiesafe、noscript、prefbar辺りを入れてprefbarでプロキシとかflashとかjavaのオンオフ管理すると良いナリ
カラッキング下準備
まず、基本となるLAMP自鯖を作って出来る限りのセキュリティを施すナリ
これでLinux系鯖の基本くらいは理解できるようにならないと侵入してもやることが無いナリ
次はツールの使い方を覚えるためにKaliLinuxとかを使って何とかして自鯖のセキュリティを破って侵入するか
自分でSQLインジェクションとかXSSとか書いて侵入するナリ
なお、簡単に入れる鯖はセキュリティ意識低いので拾ってきたバックドアでも問題無いナリ（例えばrootパスがデフォ設定の所とか）
ここまで来たら後は近所の無線をaircrack-ng等でカラッキング→tor+tsocksかproxychains辺りを使って恒心するナリ
次のうちSQLインジェクションの対策として正しいものはどれか。
ア: ユーザーの入力した文字列が、データベースへの問い合わせや操作において、意味のある文字列として解釈されないようにする。
イ: ユーザーの入力した文字列にHTMLタグが含まれていたら、HTMLタグとして解釈されない別の文字列に置き換える。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
政府向けシステムに関わったことがある身からすると、政府向けシステムの話をするときに前提として知っておいてほしいことは、住基ネット最高裁判決に「現行法上，本人確認情報の提供が認められている行政事務において取り扱われる個人情報を一元的に管理することができる機関又は主体は存在しない」という骨子があること。これによって政府向けシステムは個人情報を一元的に管理できず、個人情報は各自治体で分散管理しかできない。この文面でググれば政府がどれだけこの骨子を気にしているかは分かると思う。
今回の話は「国民マスターテーブルを持たずに認証するにはどうすべきか」という政府向けシステムで常に挙がる課題で、良いアイデアがある人は政府に提案しにいってほしい。個人情報保護法の目的外利用に違反しない上で。
これをできるのは自治体のみで防衛省はできない。防衛省は国民の住所氏名を知らないのではがきを送れない。防衛省に限らず、どの省庁も国民の住所氏名を一元的には知らないので、政府はできない。
かなり難しい。上の骨子により防衛省が個人情報を一元的に管理することができないので、最高裁判決とは条件が異なることを主張しないといけない。たとえば「都市圏だけなので一元ではない」とか。それに国民や野党が納得するかどうか。これがひろみちゅの言う「政治的にそう言えないというのはあり得るが、乗り越えなければならない」課題。
これで良いなら予約システムなんていらないけど、密を作って高齢者に何日も前から徹夜で並ばせるのが今のシステムより良いと思う？
政府が使える一元的な情報はマイナンバーしかない。マイナンバーカードを読み取れる人だけが利用できる予約システムなら認証できるけど、自治体のネット予約さえ高齢者には使えないと叩かれているのに「マイナンバーカードとリーダーが必要です」なんて要件で作れるわけがない。そもそも「短期間に多くの人に接種させる」という目的にもそぐわない。
各自治体の予約システムがAPIを持って防衛省が接種券番号の有効性をAPIで確認できれば認証できるけど、首都圏だけで200以上ある自治体がばらばらに調達しているすべての予約システムに高負荷でも落ちないAPIを共通仕様で緊急で作らせれる必要がある。けど、そんな体力があるならば自治体の予約システム自体が落ちないようにすれば良いわけで、大規模接種自体が不要かもしれない。
個人情報を一元的に管理することができる機関を立法すればできる。けど、そんなものは「たった1年」じゃ作れない。マイナンバーと住基ネットに何年掛かったと思っている？「パンデミックという緊急事態なので防衛省が高齢者の個人情報を一元的に管理することができる」世界は「戦争という緊急事態なので防衛省が20代30代男性の個人情報を一元的に管理することができる」世界につながっていることを理解した上で、国民はこの法案に賛成できるのか？ できるなら、良くも悪くも政府向けシステムの将来は大きく変わる。
結局、「国民に行政サービスを直接提供するのは自治体で、そのための個人情報を持っているのも自治体。政府は自治体を支援する」というデザインですべてが作られている日本において、菅の「政府主導でのワクチン接種」というアイデアの実現がそもそも無理ゲー。出生届や転入届を出すのは各自治体、運転免許の番号を発行しているのは各都道府県公安委員会。政府は国民の個人情報が一元的に入った共通データベースをどこにも持っていないから管理できない。従来通り、政府は自治体の支援に特化するべきだった。
中国みたいな管理国家に日本はならないという選択を国民がした時点で、この予約システムでの認証の実装の難易度は相当高い。ウイルスとの戦いに強い国は戦争にも強い国で、「人間にせよウイルスにせよ、敵との戦いに勝つために国民は政府にどれだけ一元管理されてもよいか」の総意を国民が取らないといけないので、マイナンバーや住基ネットの実績を考えると1年くらいの準備期間じゃ、みんなが期待している認証をこのシステムでは実現できない。
チェックデジットがないことで誰かの誤入力で自分の予約ができない確率が上がっているのは残念。ただ、発券しているのは各自治体なのでチェックデジットをつけられるのも各自治体なので、開発会社も防衛省もやれることはない。誰なら事前に自治体に統一仕様で作らせられたかというと厚労省だけど、接種券の仕様が決まったあとに大規模接種の話が出てきたので事後諸葛亮。こんなこともあろうかとチェックデジットの指摘が事前にできる勘が良い人がいたなら、たぶん落ちない予約システムの作り方の指摘も事前にできただろうから、大規模接種自体が不要だったかもしれない。
現状でもreCAPTCHAでBot対策されている。reCAPTCHAを越えて大量予約するやつは悪意があるので逮捕で良いでしょ。
できた。でも、接種券番号のバリデーションができない時点で大した意味はない。入力フォームの電話番号にSMS送って電話番号全体の有効性を確認することはあっても、市外局番の存在有無だけをバリデーションするなんてことしないでしょ。入力された市外局番と市外局番マスターを引きあててバリデーションをしている者だけが石を投げられる。
防衛省は生年月日の正しい情報を持っていないので、この数字に大した意味はない。たぶん予約キャンセル用のパスワード相当、当日の誤入力を見つけるためのヒントくらいの意味しかない。「パスワードを設定してください」でも良かったんだけど、高齢者には難易度が高いと思って生年月日にしたんだろう。秘密の質問みたいなもの。あなたの母親の旧姓が本当に正しいかどうかにシステム側は興味がないのと同じくらい、この生年月日が正しいかどうかに大規模接種予約システムは興味がない。
いまだに具体例が出てこないので、多分ガセ
異なる市町村番号＋同じ接種券番号＋異なる生年月日でログインできないことで接種券番号だけがユニークと主張しているけど、ログインできない理由はそれだけじゃない。たとえば2-123,5678がすでに登録されていることをこの人は知らない状況で、この人は1-123,1234でログインできるけど、2-123,7890はログインできない。システムとしておかしくない。
よくあるコメントに返信。
法律は素人のシステム屋なので、この指摘は正しいのかもしれない。一方で「個人情報とは個人を一意に識別できる情報のことを指すもの」というコメントもある。私には判断できないけど、仮に個人情報ではないとすると、
かなり難しい。上の骨子により防衛省が個人情報を一元的に管理することができないので、最高裁判決とは条件が異なることを主張しないといけない。たとえば「接種券番号は個人情報ではない」とか「都市圏だけなので一元ではない」とか。それに国民や野党が納得するかどうか。これがひろみちゅの言う「政治的に（『接種券番号と生年月日は個人情報ではないので一元管理します』とは）言えないというのはあり得るが、乗り越えなければならない」課題。
が正しいのかもしれない。住基ネット最高裁判決によって政府向けシステムに認証機能をつけることは想像以上に難しいという趣旨は変わらないけど、悪いのは菅じゃなくて「個人情報ではない」で突っ張れなかった防衛省なのかもね。いずれにせよ「認証すらまともに作れない技術力」から「接種券番号は個人情報なのか」に議論が高まってくれれば書いた甲斐があった。
VRSってのは各自治体の接種会場で使われているバーコードがなくてOCRが必要なことで有名なシステム。OCRは置いておいて、VRSは一元管理していない。 https://cio.go.jp/sites/default/files/uploads/documents/vrs_overview_210506.pdf の6ページ目に書いてある。
＞市区町村ごとに区切られて保存されており、個人の記録は、接種券を発行した市区町村が確認できます
国民の接種率が重要指標なんだからDBは1個にしたほうが便利なのに、「あえて」区切って保存している。また、個人の記録は各市区町村しか確認できい、つまり串刺しで全国民の個人記録を見られる人はいないと書いてある。そんなわけでVRSは「政府は一元管理していません」に気を使っていることが分かる事例。
スクリプト組んで乱数で大量に空予約を登録なんてことはできなくなってる。
例えば3月30日生まれの人が間違えて2月30日を入力していたとしても、受付で人が判断してそのまま接種させればいい。
受付で本人確認する。
上記のように3月30日生まれの人が間違えて2月30日になるくらいならそのまま受け付ければいいが、あまりにも入力内容と本人の属性が異なってたら、見たらわかるだろ。
◾️予約済み番号が二度入る
誤入力で他人の予約を意図せず上書きしてしまうというのは起こり得る。
これは問題だから、予約者に予約完了メールを送るようにシステムを修正するべきかもしれない。
1%の人間が誤入力でシステム上の予約日と違う日に来ても、1万人が１万100人になるレベルだから、受付で予約完了メールが確認できれば、そのまま接種させればいい。
ここだけは改善点として挙げられる。
◾️SQLインジェクションできる
twitterで噂になってるから探したけどソースが見つからないんだよね。デマじゃないの？
金融機関のシステムでもないのに、本人確認などかっちりシステム作って、稼働は1ヶ月後ですってなったら、その間にワクチン打てた30万回が遅れることになる。
ワクチン大規模接種東京センターの予約システムで発生した、適当な数字を入力しても予約できるシステムの不備はバグなのか脆弱性(セキュリティホール)なのかを考えていこう。
もし、脆弱性であるとするならば、しかるべき報告フローを取る必要があるからだ。
記事の末尾に参考リンクをいろいろおいておいたので、詳細は確認してほしい。
この問題は、本来するべきチェック処理をしていないのだから、バグの一種といえる。
// ただ、改善する気がないのなら仕様となるのだろうけどね。
では、適当な数字を入れても予約できちゃうバグは、脆弱性(セキュリティホール)と言えるのか？
もし、脆弱性(セキュリティホール)となるなら、ゼロディでいきなり公開する前に、しかるべき報告フローを取るべきだ。
// ただ、新聞社は、ネットで噂になったものを取材して報道しただけであるから、ゼロディで公開とは言えないだろうけどな。
これはタダのバグであって、脆弱性(セキュリティホール)と呼ぶのは言い過ぎだろう。
例えば、教科書レベルの「"＜script＞alert("XSS");＜/script＞」でXSSを発生させる意図的な入力をして、誤動作が発生するなら、それは間違いなく脆弱性(セキュリティホール)といえる。
同様に、SQLインジェクションを発生させる意図的な入力をして、何か変なことが起きれば、これも間違いなく脆弱性といえる。
他にも、超でかいデータを送りつけてバッファオーバーフローさせたり、特殊な入力をしてスタックを破壊して戻り値を改ざんして任意のコマンドを実行するみたいなものも同様に脆弱性と呼んでもいいだろう。
(注:念のために書いておくが、不正アクセスで違法になる可能性があるので、自分の所有するサイトやコンピュータ以外へは、これらの入力を試さないように。)
でも、ごく普通の入力をしても、エラーとしてはじかないで受け入れてしまうのは、脆弱性ではなく、タダのバグであるように思う。
「こういう操作したら、計算結果が変になった」はバグの領域であって、脆弱性とまでは言えない。
今までの話を簡単に言うとしたら、ドラクエ4で8回逃げたら会心の一撃が連続して出るのはバグなのか脆弱性なのか？って話になるのかな。
確かに、8回逃げることで、データのバッファオーバーフローが発生して、そのような結果になる。
でも、8回逃げるというはやろうと思えは誰でもできる動作であって、これをバグではなく脆弱性(セキュリティホール)と呼ぶのは違和感がある。
この裏技を見つけたとして、脆弱性としてしかるべき報告フローを取らずに公開したことを咎められるとしたら、実に変な話である。
これら裏技を試しても不正アクセスと言われて、罪を着せられたり、裏技の記事を削除されるとしたら、強烈な違和感がある。
今回の事件で、それが一番気になった。
最終的には、裁判で裁判所が決めることになるんだろうけど、あまりアホな判決を出して、日本のエンジニアの手足を拘束しないでほしいと思う。
参考URL:
■ドラクエ４で「にげる」８回でずっと会心の一撃になるバグ、こういう仕組みで起こってたらしい
https://b.hatena.ne.jp/entry/s/togetter.com/li/1715732
■「誰でも何度でも予約可能」ワクチン大規模接種東京センターの予約システムに重大欠陥
https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html
■岸信夫 on Twitter: "自衛隊大規模接種センター予約の報道について。...
https://b.hatena.ne.jp/entry/s/twitter.com/KishiNobuo/status/1394440062125805572
■脆弱性の手口、IPA「見つけたらまず開発者やIPA窓口に報告して」 コロナワクチンの架空予約巡り
https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2105/18/news145.html
■Hiromitsu Takagi on Twitter: "私はこの届出制度の提唱者・設計者・運用協力者・有識者研究会委員であり、IPAの広報が取材にこんな回答をしたのであれば、出鱈目であり、...
https://b.hatena.ne.jp/entry/s/twitter.com/HiromitsuTakagi/status/1394713619212816385
■ワクチン大規模接種「架空ウェブ予約」やったら犯罪？ 国は「法的手段」に言及
https://b.hatena.ne.jp/entry/s/www.bengo4.com/c_23/n_13071/
■確認作業は公益性高い、毎日新聞 接種センター架空入力は取材目的
https://b.hatena.ne.jp/entry/s/this.kiji.is/767285347672670208
https://b.hatena.ne.jp/entry/s/dot.asahi.com/info/2021051900065.html
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 109 | 14551 | 133.5 | 57 |
| 01 | 83 | 10345 | 124.6 | 43 |
| 02 | 34 | 5286 | 155.5 | 76 |
| 03 | 39 | 4085 | 104.7 | 46 |
| 04 | 63 | 5246 | 83.3 | 68 |
| 05 | 80 | 4931 | 61.6 | 46 |
| 06 | 19 | 3223 | 169.6 | 49 |
| 07 | 60 | 9865 | 164.4 | 49.5 |
| 08 | 77 | 7429 | 96.5 | 26 |
| 09 | 191 | 14529 | 76.1 | 39 |
| 10 | 194 | 14211 | 73.3 | 43.5 |
| 11 | 186 | 16662 | 89.6 | 45 |
| 12 | 166 | 15917 | 95.9 | 37 |
| 13 | 135 | 8173 | 60.5 | 33 |
| 14 | 199 | 13742 | 69.1 | 34 |
| 15 | 167 | 14155 | 84.8 | 38 |
| 16 | 176 | 15285 | 86.8 | 36.5 |
| 17 | 192 | 15347 | 79.9 | 36.5 |
| 18 | 126 | 13863 | 110.0 | 41 |
| 19 | 142 | 17051 | 120.1 | 30 |
| 20 | 175 | 13820 | 79.0 | 33 |
| 21 | 134 | 9048 | 67.5 | 23.5 |
| 22 | 94 | 12778 | 135.9 | 44 |
| 23 | 120 | 19235 | 160.3 | 54.5 |
| 1日 | 2961 | 278777 | 94.1 | 39 |
SQLインジェクション(8), 新安(4), 保法(4), 水からの伝言(4), ひろみちゅ(22), セックル(3), 高木先生(3), 徳丸(4), カイドウ(4), usagi(5), ガザ地区(3), ベーシックインカム(25), 接種(53), 予約(64), 文法(11), 飼う(11), 所得税(11), 番号(20), ひろゆき(12), 処女(26), ワクチン(93), 学術(16), 権威(13), システム(96), 共産党(17), 大規模(15), ウマ娘(24), マスコミ(22), 弱者男性(72), IT(36), 科学(19), 救わ(20), 政府(60)
■みんなやってるけど公には言わないグレーな行為 /20210518100156(75), ■葬式シーンで雨が降ってるとムカつく病 /20210517205623(25), ■マジでいいところまで書いてて死んでしまった作家 /20210518144014(20), ■中国韓国との競争に敗れ衰退が続く日本の造船業について /20210518071533(18), ■ワクチン予約のクソシステムについての私見 /20210517201151(16), ■5大、終わらせる気がなさそうなダラダラ漫画 /20210518111230(16), ■彼女の実家と家族がドカタであることが判明してショックだった /20210518195105(14), ■母がハマってきたものと最近のトレンド /20210518063647(14), ■まじめな話、男のどのくらいが処女厨なん？ /20210518112052(13), ■弱者男性に１番厳しい属性ってフェミ男性なんだな /20210517201726(13), ■科学リテラシーって要するに権威主義って認識であってる？ /20210516225443(11), ■本当の「弱者男性の丁寧な生活」 /20210517213621(11), ■スピリチュアルにハマる母についての考察 /20210518113034(11), ■疲れたから聞いてくれ /20210518140340(9), ■ワクチン予約のシステム、納期ありきのクソプロジェクトあるあるすぎ /20210517234543(9), ■結局なぜ満員電車で大規模感染が引き起こされなかったのかの答えは出ていない /20210517170136(9), ■出先上司「増田くん平成産まれだから円周率は3なんでしょ」 /20210518105636(9), ■有明アリーナが電通に1/5の価格で譲渡される件のカラクリ /20210517222926(9), ■孫子は巧遅より拙速なんていってない /20210518113524(8), ■anond：20210518160647 /20210518161458(8)
やるべきことはひとつです。
https://www.ipa.go.jp/security/vuln/report/
https://www.npa.go.jp/cyber/kanminboard/siryou/sec_hole/partnership.html
間違っても、5chに「SQLインジェクションできる」などと書き込んだり、個人のブログで脆弱性をつく手口を公開したりすべきではありません。
また、それらの情報を粗雑な粒度でまとめたツイートやまとめサイト記事などの拡散に協力すべきでもありません。
上記の行為は、法的責任に問われる可能性があるだけでなく、当該サイトを攻撃のリスクに晒す行為でもあります。
もちろん、日々圏論やデータ分析の記事をブクマし、技術力の向上に努める技術寄りのはてな民が情報セキュリティ教育の基礎の基礎をすっ飛ばしているとは思いませんので、釈迦に説法とは思いますが、一応のリマインドとして置いておきます。
